You can use 128 bit challenge for the PoK (give up batch verification)
Oh that’s interesting. You reveal the bytes *with* the PoK. Ok then I raise you: We use BLS where the PoK is deterministic.
.
Login to reply
Replies (3)
Def chat more about this! I'm busy but will answer tomorrow :)
First, check the recent discussion on the mailing list (on inability to embed data in schnorr), a few interesting thoughts about this model there (i was limiting discussion to P, R, s outputs, i claimed secret key revelation is inevitable if you do publish, ajtowns point in particular (but not only) is very interesting that you can actually get round that limitation in practice, on bitcoin, even if not in theory).
Currently I'm writing up a small presentation on this topic and got to thinking about the deeper point: ZK (pok or w/e) requires blinding, which requires randomness. Data can be embedded in that but the devil's in the details. A funny example: imagine choosing to do RFC6979 with a ZKP of correctness, so the randomness is deterministic and constrained; but here, if say the ZKP is Groth16 (just an e.g.), it itself contains randomness that could be similarly misused (I think? not sure yet).
As for your BLS example: good point. It's not a ZKP system, it relies on a computational assumption, it's one-shot so you do, I agree, get the property you need: deterministic without wiggle room for data embedding (I think!). But ... there's actually no way that could or would be implemented on bitcoin (btw were you imagining *only* the PoK as BLS? that seems messy).
https://eprint.iacr.org/2022/1263 looks like a relevant paper!