Delivery-date: Wed, 01 Oct 2025 16:04:57 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::532 as permitted sender) client-ip=2607:f8b0:4864:20::532;
MIME-Version: 1.0
References: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.com>
In-Reply-To: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.com>
From: Greg Maxwell <gmaxwell@gmail.com>
Date: Wed, 1 Oct 2025 22:10:16 +0000
Message-ID: <CAAS2fgQRz=EJ+Nm2rxrB_SEpqroFbcc+hUhmghJJ1jrJc-WUDA@mail.gmail.com>
Subject: Re: [bitcoindev] On (in)ability to embed data into Schnorr
To: "waxwing/ AdamISZ" <ekaggata@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000d37ae80640202275"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--000000000000d37ae80640202275
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Intuitively it sounds likely, -- just in that the available values are a
image on the curve and a value summed with a hash dependent on everything
else.  I think it would be hard to prove.

But is it even really worth the analysis when grinding gets you a 12%
embedding rate in that signature at not that significant cost? (because you
can independently grind the nonce and signature itself, or nonce and
pubkey) -- and when beyond the cost of the additional signature (making the
output 3x its cost) requiring signing when forming the address completely
kills public derivation, multisig with cold keys. etc?  ... and then any of
whatever spam concerns people have would likely be exacerbated by the
spammers using more resources due to the embedding rate?

Also re private key leaking an utxo set, well not so if it's part of an
explicit multisig. E.g. 2 of 2 with leaked key and a secure one.


On Wed, Oct 1, 2025 at 7:50=E2=80=AFPM waxwing/ AdamISZ <ekaggata@gmail.com=
> wrote:

> 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, y=
ou
> 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 b=
y
> 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-6938=
4dcc4086n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/0f6c92cc-e922-4d9f-9fdf-693=
84dcc4086n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CAAS2fgQRz%3DEJ%2BNm2rxrB_SEpqroFbcc%2BhUhmghJJ1jrJc-WUDA%40mail.gmail.com.

--000000000000d37ae80640202275
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Intuitively it sounds likely, -- just in that the ava=
ilable values are a image on the curve and a value summed with a hash depen=
dent on everything else.=C2=A0 I think it would be hard to prove.</div><div=
><br></div><div>But is it even really worth the analysis when grinding gets=
 you a 12% embedding rate in that signature at not that significant cost? (=
because you can independently grind the nonce and signature itself, or nonc=
e and pubkey) -- and when beyond the cost of the additional signature (maki=
ng the output 3x its cost) requiring signing when forming the address compl=
etely kills public derivation, multisig with cold keys. etc?=C2=A0 ... and =
then any of whatever spam concerns people have would likely be exacerbated =
by the spammers using more resources due to the embedding rate?</div><div><=
br></div><div>Also re private key leaking an utxo set, well not so if it=
9;s part of an explicit multisig. E.g. 2 of 2 with leaked key and a secure =
one.</div><div><br></div><div><br></div><div><br></div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Wed, Oct 1, 2025 at 7:50=E2=80=AFPM waxwing/ AdamISZ &lt;<a href=3D"ma=
ilto:ekaggata@gmail.com">ekaggata@gmail.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">Hi all,<div><br></div><div><a hr=
ef=3D"https://github.com/AdamISZ/schnorr-unembeddability/" target=3D"_blank=
">https://github.com/AdamISZ/schnorr-unembeddability/</a></div><div><br></d=
iv><div>Here I&#39;m analyzing whether the following statement is true: &qu=
ot;if you can embed data into a (P, R, s) tuple (Schnorr pubkey and signatu=
re, BIP340 style), without grinding or using a sidechannel to &quot;inform&=
quot; the reader, you must be leaking your private key&quot;.</div><div><br=
></div><div>See the abstract for a slightly more fleshed out context.</div>=
<div><br></div><div>I&#39;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-a=
ffirmative: 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 emphasi=
ze, this is different to the earlier observations (including by me!) that j=
ust say it is *possible* to leak data by leaking the private key; here I=
9;m trying to prove that there is *no other way*).</div><div><br></div><div=
>However I still am probably in the large majority that thinks it&#39;s app=
alling to imagine a sig attached to every pubkey onchain.</div><div><br></d=
iv><div>Either way, I found it very interesting! Perhaps others will find t=
he analysis valuable.</div><div><br></div><div>Feedback (especially of the =
&quot;that&#39;s wrong/that&#39;s not meaningful&quot; 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" target=
=3D"_blank">bitcoindev+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&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/0f6c92cc-e922-4d9f-9fdf-69384dcc4086n%40googlegrou=
ps.com</a>.<br>
</blockquote></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/CAAS2fgQRz%3DEJ%2BNm2rxrB_SEpqroFbcc%2BhUhmghJJ1jrJc-WUDA%40mail=
.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.co=
m/d/msgid/bitcoindev/CAAS2fgQRz%3DEJ%2BNm2rxrB_SEpqroFbcc%2BhUhmghJJ1jrJc-W=
UDA%40mail.gmail.com</a>.<br />

--000000000000d37ae80640202275--