Delivery-date: Thu, 02 Oct 2025 09:17:28 -0700
Sender: bitcoindev@googlegroups.com
Date: Thu, 2 Oct 2025 08:56:01 -0700 (PDT)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <cf15c24e-18d0-4221-a3d4-4177c82a6381n@googlegroups.com>
In-Reply-To: <2e366b25-f789-4c9d-acf9-b87149d6a796n@googlegroups.com>
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>
Subject: Re: [bitcoindev] On (in)ability to embed data into Schnorr
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_295280_39685520.1759420561201"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_295280_39685520.1759420561201
Content-Type: multipart/alternative; 
	boundary="----=_Part_295281_1049530429.1759420561201"

------=_Part_295281_1049530429.1759420561201
Content-Type: text/plain; charset="UTF-8"

> >  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 if 
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 bit 
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 sense 
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 the 
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 something 
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 it 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 possible 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-4177c82a6381n%40googlegroups.com.

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

&gt; &gt;=C2=A0=C2=A012% embedding rate<div>&gt; Where do you get that numb=
er from? 33% for embedding 256 bits in (P, R, s) (but as per this discussio=
n, according to me, at the cost of key leakage). If we include the other by=
tes in a (taproot anyway) utxo that's not much less, I guess 30% ish. I cou=
ld try to guess=C2=A0but it'd be easier if you told me :)</div><div><br /><=
/div><div>Thinking about it again: to publish data, you have to publish a t=
ransaction! I guess the most economical, paying taproot to taproot, is abou=
t 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 bit dif=
ferent for key path though, because no control block? Well it hardly matter=
s, it's some small fraction in that range.</div><div><br /></div><div>An in=
teresting mechanical detail in this near-absurd scenario is that if you wan=
ted 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" sce=
nario that Greg mentioned, which I think would only make sense with legacy =
script? Kind of a different scenario, also it would be really weird to upda=
te legacy script to take into account a new "you must sign the pubkeys" rul=
e. 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 yo=
u did it with taproot due to how that works, the script is not published un=
til the output is spent, so I think that's outside what I was considering (=
"data in utxo set"). (I guess you could also use something like a hash lock=
 which might be more efficient). So anyway if you wanted to do this repeate=
dly 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.</div><div=
><br /></div><div>But that all became way too hypothetical to even analyze =
properly :)</div><div><br /></div><div>Anyway just to reemphasize I certain=
ly wasn't advocating this sig-attaching system, but it seems important to k=
now what the result of it would be: we would still not have changed the obv=
ious 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 b=
e 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.</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">bitcoind=
ev+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&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/cf15c24e-18d0-4221-a3d4-4177c82a6381n%40googlegroups.com</a>.<br />

------=_Part_295281_1049530429.1759420561201--

------=_Part_295280_39685520.1759420561201--