Delivery-date: Wed, 01 Oct 2025 12:50:44 -0700
Sender: bitcoindev@googlegroups.com
Date: Wed, 1 Oct 2025 07:24:50 -0700 (PDT)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.com>
Subject: [bitcoindev] On (in)ability to embed data into Schnorr
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_126442_663939594.1759328690860"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_126442_663939594.1759328690860
Content-Type: multipart/alternative; 
	boundary="----=_Part_126443_1781324974.1759328690860"

------=_Part_126443_1781324974.1759328690860
Content-Type: text/plain; charset="UTF-8"

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.

------=_Part_126443_1781324974.1759328690860
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,<div><br /></div><div>https://github.com/AdamISZ/schnorr-unembeddabi=
lity/</div><div><br /></div><div>Here I'm analyzing whether the following s=
tatement is true: "if you can embed data into a (P, R, s) tuple (Schnorr pu=
bkey and signature, BIP340 style), without grinding or using a sidechannel =
to "inform" the reader, you must be leaking your private key".</div><div><b=
r /></div><div>See the abstract for a slightly more fleshed out context.</d=
iv><div><br /></div><div>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.</div><div><br /></div><div>(To emph=
asize, this is different to the earlier observations (including by me!) tha=
t 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*).</div><div><br /></div><di=
v>However I still am probably in the large majority that thinks it's appall=
ing to imagine a sig attached to every pubkey onchain.</div><div><br /></di=
v><div>Either way, I found it very interesting! Perhaps others will find th=
e analysis valuable.</div><div><br /></div><div>Feedback (especially of the=
 "that's wrong/that's not meaningful" variety) appreciated.</div><div><br /=
></div><div>Regards,</div><div>AdamISZ/waxwing</div><div><br /></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/0f6c92cc-e922-4d9f-9fdf-69384dcc4086n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/0f6c92cc-e922-4d9f-9fdf-69384dcc4086n%40googlegroups.com</a>.<br />

------=_Part_126443_1781324974.1759328690860--

------=_Part_126442_663939594.1759328690860--