> if you can embed data into a (P, R, s) tuple (Schnorr pubkey and signature, BIP340 style), without grinding or using a sidechannel to "inform" the reader, you must be leaking your private key

You can embed data into a valid signature. For example:

R=k*G
P=d*G
k=first_chunk_of_data
d=second_chunk_of_data

And then, keys are "weak", because people can use "known plaintext attack", to get them. However, if you want to push random data, that is unknown to the reader, then it is known only by the holder of the data.

Which means, that the efficiency of this encoding is somewhere around 66%, by grinding SHA-256 hashes, it could probably reach around 70% in practice. Only s-value is something, that needs any grinding, for k-value and d-value, you need only the data, and nothing else.

So, I guess it is a spectrum: something like 70% efficiency means, that you need "known plaintext attack" to get the data. And then, you can use less and less bits per public key, to make it arbitrarily weaker. Then, instead of relying on a timelock, you can rely on computation difficulty for the reader, for example: "how many bits I need to leak, to make it breakable by lattice attack".

śr., 1 paź 2025 o 21:50 waxwing/ AdamISZ <ekaggata@gmail.com> napisał(a):

Hi all,

https://github.com/AdamISZ/schnorr-unembeddability/

Here I'm analyzing whether the following statement is true: "if you can embed data into a (P, R, s) tuple (Schnorr pubkey and signature, BIP340 style), without grinding or using a sidechannel to "inform" the reader, you must be leaking your private key".

See the abstract for a slightly more fleshed out context.

I'm curious about the case of P, R, s published in utxos to prevent usage of utxos as data. I think this answers in the half-affirmative: you can only embed data by leaking the privkey so that it (can) immediately fall out of the utxo set.

(To emphasize, this is different to the earlier observations (including by me!) that just say it is *possible* to leak data by leaking the private key; here I'm trying to prove that there is *no other way*).

However I still am probably in the large majority that thinks it's appalling to imagine a sig attached to every pubkey onchain.

Either way, I found it very interesting! Perhaps others will find the analysis valuable.

Feedback (especially of the "that's wrong/that's not meaningful" variety) appreciated.

Regards,
AdamISZ/waxwing

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0f6c92cc-e922-4d9f-9fdf-69384dcc4086n%40googlegroups.com.