Delivery-date: Thu, 02 Oct 2025 14:59:48 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::530 as permitted sender) client-ip=2607:f8b0:4864:20::530;
MIME-Version: 1.0
References: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.com>
 <CAAS2fgQRz=EJ+Nm2rxrB_SEpqroFbcc+hUhmghJJ1jrJc-WUDA@mail.gmail.com>
 <aN21KbXTORgXAVH0@mail.wpsoftware.net> <2e366b25-f789-4c9d-acf9-b87149d6a796n@googlegroups.com>
 <cf15c24e-18d0-4221-a3d4-4177c82a6381n@googlegroups.com>
In-Reply-To: <cf15c24e-18d0-4221-a3d4-4177c82a6381n@googlegroups.com>
From: Greg Maxwell <gmaxwell@gmail.com>
Date: Thu, 2 Oct 2025 19:49:10 +0000
Message-ID: <CAAS2fgQtx_FnecKxpKryTq9o5HJfirY_Vyih6FXzHGHG2itmQQ@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="0000000000001c72330640324859"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

I just meant in the purely grinding non-key leaking case you could get 4
bytes into the nonce pretty easily and 4 bytes into either the pubkey or
signature out of a 64 byte signature.  Obviously the delivered embedding
rate in a whole txn will be lower, but maybe not that much thanks to
multisig outputs.


On Thu, Oct 2, 2025 at 4:17=E2=80=AFPM waxwing/ AdamISZ <ekaggata@gmail.com=
> wrote:

> > >  12% embedding rate
> > Where do you get that number from? 33% for embedding 256 bits in (P, R,
> s) (but as per this discussion, according to me, at the cost of key
> leakage). If we include the other bytes in a (taproot anyway) utxo that's
> not much less, I guess 30% ish. I could try to guess but it'd be easier i=
f
> you told me :)
>
> Thinking about it again: to publish data, you have to publish a
> transaction! I guess the most economical, paying taproot to taproot, is
> about 192 bytes with script path plus the posited extra 64 for the (R,s) =
in
> the output, so yeah that'd be 32 out of 256, 12.5%. Isn't the figure a bi=
t
> different for key path though, because no control block? Well it hardly
> matters, it's some small fraction in that range.
>
> An interesting mechanical detail in this near-absurd scenario is that if
> you wanted to repeatedly publish off the same (presumably a few multiples
> of dust level) output, you couldn't also do the leak single key thing,
> since you'd lose control to re-spend. So that'd place us in the "explicit
> multisig" scenario that Greg mentioned, which I think would only make sen=
se
> with legacy script? Kind of a different scenario, also it would be really
> weird to update legacy script to take into account a new "you must sign t=
he
> pubkeys" rule. Though I guess in this fictional scenario, it might happen
> like that. If you did do it with legacy, you'd be publishing bare 2 of 2
> multisig. If you did it with taproot due to how that works, the script is
> not published until the output is spent, so I think that's outside what I
> was considering ("data in utxo set"). (I guess you could also use somethi=
ng
> like a hash lock which might be more efficient). So anyway if you wanted =
to
> do this repeatedly and minimize cost, for whatever strange reason, you'd =
be
> adding another 50-100 bytes each time bringing that % down to like 10% or
> less.
>
> But that all became way too hypothetical to even analyze properly :)
>
> Anyway just to reemphasize I certainly wasn't advocating this
> sig-attaching system, but it seems important to know what the result of i=
t
> would be: we would still not have changed the obvious reality that
> embedding data in witness gives more space for data, and is more
> economical, and we would only reduce by a big factor how much can be
> embedded in outputs (anything from 8% to 15% embedding rate seems possibl=
e
> depending on the hypothetical details), while having to screw up much of
> Bitcoin's functionality in the process.
>
> Cheers,
> 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/cf15c24e-18d0-4221-a3d4-4177=
c82a6381n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/cf15c24e-18d0-4221-a3d4-417=
7c82a6381n%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/=
CAAS2fgQtx_FnecKxpKryTq9o5HJfirY_Vyih6FXzHGHG2itmQQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div>I just meant in the purely grinding non-key leaking c=
ase you could get 4 bytes into the nonce pretty easily and 4 bytes into eit=
her the pubkey or signature out of a 64 byte signature.=C2=A0 Obviously the=
 delivered embedding rate in a whole txn will be lower, but maybe not that =
much thanks to multisig outputs.</div><div><br></div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Thu, Oct 2, 2025 at 4:17=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">&gt; &gt;=C2=A0=C2=A012% embeddi=
ng rate<div>&gt; Where do you get that number from? 33% for embedding 256 b=
its in (P, R, s) (but as per this discussion, according to me, at the cost =
of key leakage). If we include the other bytes in a (taproot anyway) utxo t=
hat&#39;s not much less, I guess 30% ish. I could try to guess=C2=A0but it&=
#39;d be easier if you told me :)</div><div><br></div><div>Thinking about i=
t again: to publish data, you have to publish a transaction! I guess the mo=
st economical, paying taproot to taproot, is about 192 bytes with script pa=
th plus the posited extra 64 for the (R,s) in the output, so yeah that&#39;=
d be 32 out of 256, 12.5%. Isn&#39;t the figure a bit different for key pat=
h though, because no control block? Well it hardly matters, it&#39;s some s=
mall fraction in that range.</div><div><br></div><div>An interesting mechan=
ical detail in this near-absurd scenario is that if you wanted to repeatedl=
y publish off the same (presumably a few multiples of dust level) output, y=
ou couldn&#39;t also do the leak single key thing, since you&#39;d lose con=
trol to re-spend. So that&#39;d place us in the &quot;explicit multisig&quo=
t; scenario that Greg mentioned, which I think would only make sense with l=
egacy script? Kind of a different scenario, also it would be really weird t=
o update legacy script to take into account a new &quot;you must sign the p=
ubkeys&quot; rule. Though I guess in this fictional scenario, it might happ=
en like that. If you did do it with legacy, you&#39;d be publishing bare 2 =
of 2 multisig. If you did it with taproot due to how that works, the script=
 is not published until the output is spent, so I think that&#39;s outside =
what I was considering (&quot;data in utxo set&quot;). (I guess you could a=
lso use something like a hash lock which might be more efficient). So anywa=
y if you wanted to do this repeatedly and minimize cost, for whatever stran=
ge reason, you&#39;d be adding another 50-100 bytes each time bringing that=
 % down to like 10% or less.</div><div><br></div><div>But that all became w=
ay too hypothetical to even analyze properly :)</div><div><br></div><div>An=
yway just to reemphasize I certainly wasn&#39;t advocating this sig-attachi=
ng system, but it seems important to know what the result of it would be: w=
e would still not have changed the obvious reality that embedding data in w=
itness gives more space for data, and is more economical, and we would only=
 reduce by a big factor how much can be embedded in outputs (anything from =
8% to 15% embedding rate seems possible depending on the hypothetical detai=
ls), while having to screw up much of Bitcoin&#39;s functionality in the pr=
ocess.</div><div><br></div><div>Cheers,</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/cf15c24e-18d0-4221-a3d4-4177c82a6381n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/cf15c24e-18d0-4221-a3d4-4177c82a6381n%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/CAAS2fgQtx_FnecKxpKryTq9o5HJfirY_Vyih6FXzHGHG2itmQQ%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAAS2fgQtx_FnecKxpKryTq9o5HJfirY_Vyih6FXzHGHG2itmQQ%40mail.g=
mail.com</a>.<br />

--0000000000001c72330640324859--