From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 06 Oct 2025 06:06:37 -0700 Received: from mail-oo1-f63.google.com ([209.85.161.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v5kvE-0001KO-B9 for bitcoindev@gnusha.org; Mon, 06 Oct 2025 06:06:37 -0700 Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-64672a643desf6094055eaf.2 for ; Mon, 06 Oct 2025 06:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1759755990; x=1760360790; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=zXpOPipVmGtVyoTCD5KeH2kLkQeRrJUAF0PuVax7qxc=; b=nTgrdSgIFUGUt9/cWxKzLvF6EmAkQEXvWgl8Pid5XZcNfUklLy0QfRJHpmxFtAeM03 mykT+q2yBVve/9jzvCyVWNGD+WjcLBSKgo6WpDGyR+L6sWhsER4OjHnJt1eHnaUUa9FE maoKn1HnbJriVjLis00fmPUL6++7q1TDXMbho1fmF96IctoEhQHNR2/tw75Af/eKfs4W yqU6WDydbaJkYex5XdQT8v8qNrT0Tmdelv2l5COYk7ijo/ZKIdGeeBPMwZM8yBfmTZox Kks+U15Xg/L1jzpyCsn83GOn0jpz2mz/V3SkOpAPmLxy3pmq3aj2hRpDMaMPWo3qvMw8 WW8g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759755990; x=1760360790; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=zXpOPipVmGtVyoTCD5KeH2kLkQeRrJUAF0PuVax7qxc=; b=bnwBXNMAE+4hfGCd2UQDbyveGKC8FisUyaaHFTMgLFSen/vVeC6+eSD6CvfHrQ1W4i olrvSNMga99yGDab0FzwxXnXyOVj4s1jVNEibsBSS7fV/658MLnevc/8f9gV4pDvAq0P ZPAdDD/Qppy1+8T82MPbx9B0yqENeob0Z8FL3Xjqt9HOoGuhNvbaadUW2dGDiHDxWqu/ t46ZpcBuVRn5GqxiWxiWPmB237tFfvz4fXrsYBynFtTjytHrGeFdS/1Ji4wBkeMDpTmK mr1LRn13IMg2Enz2AaU1Ap3E6k5Fw6VluXky6GAE2FBVkgmlZcvMpNr0fGnZLZTrvn0Q pyLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759755990; x=1760360790; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=zXpOPipVmGtVyoTCD5KeH2kLkQeRrJUAF0PuVax7qxc=; b=eAnzhfvx9UOx26kYWGe84BiwlemhZ6nrOSJPib0uP9VRy9LDgR1iVnn95vW0PIAtgp RHwxvostcUL2gfmv8p90+cySvIxLDGyn4MfDBSYMKSYnhmk512kw3aN1pHxGVvM9vSI0 o6jbqUXZXslUgcGO2QZIb4V4E06ORM2kqgDwOIF6scymvVJDxBbKnIBIo8P87jjlOYMS t2TXrqL7w52maVgShYNK/ceUMQi7SMFGNaBn7fxamk6SxzBbXCHB1t9YvYWTV7g/1rtw JmZUGddBv+WIKrW5GkyDA/Cc/TGCq7Q1lrmPf5XfmgH/jRj3HNynkkMVLRxX8/SbGVN2 IDhg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUNld4LqG848RiQLtxjiuK2zLLIK8m2QMNnZEHCR/8O8DoMQFoOBpM9rGdnao3cKg0HA/OAGSNNSIxT@gnusha.org X-Gm-Message-State: AOJu0YyRQd2VQmdwr9DHqbwRhM4dZdz1ereU48mbIQL5tx6aDOjjTaWN AKR6drm7KlHwHRF9IsgG+8Yaw9YNsLIrUUIPWKchK7mA+/5HhhO8Y9d9 X-Google-Smtp-Source: AGHT+IFTXeQbJMwu7c5VmdAETkFrMrlBDudDQy1Kr7BFNFlyIaZ03RyJGaf7/SuDweFRFIlTiFu5jg== X-Received: by 2002:a05:6870:e08c:b0:3ae:f15:5df3 with SMTP id 586e51a60fabf-3b0f8b041ecmr8020706fac.27.1759755989874; Mon, 06 Oct 2025 06:06:29 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd6b6lFO7KSzLSNB0Bv4tX5pZ84RT9wC8fD8NPPzw9yvWQ==" Received: by 2002:a05:6871:ae82:b0:3a9:7d42:2984 with SMTP id 586e51a60fabf-3abffcc5b05ls1567674fac.1.-pod-prod-05-us; Mon, 06 Oct 2025 06:06:25 -0700 (PDT) X-Received: by 2002:a05:6808:4f4f:b0:43f:4d50:3352 with SMTP id 5614622812f47-43fc17fc151mr6035691b6e.31.1759755985497; Mon, 06 Oct 2025 06:06:25 -0700 (PDT) Received: by 2002:a05:690c:ed6:b0:725:2535:e36 with SMTP id 00721157ae682-77f93fd870bms7b3; Mon, 6 Oct 2025 06:04:47 -0700 (PDT) X-Received: by 2002:a53:d809:0:b0:635:4ecd:5fca with SMTP id 956f58d0204a3-63b9a0f2962mr9646241d50.39.1759755887178; Mon, 06 Oct 2025 06:04:47 -0700 (PDT) Date: Mon, 6 Oct 2025 06:04:46 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.com> <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_201424_1075981190.1759755886831" X-Original-Sender: ekaggata@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_201424_1075981190.1759755886831 Content-Type: multipart/alternative; boundary="----=_Part_201425_620897329.1759755886831" ------=_Part_201425_620897329.1759755886831 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, sorry, reading fail on my part (somehow missed that you were=20 explicitly referring to grinding in the comment). Still don't think the 12% figure is a good one though? in (P,R,s) it's 8=20 out of 96 (and as discussed, worse if whole tx is (realistically)=20 included), 1/4 the rate you get from direct key leakage. (Plus the perhaps= =20 trivial point that it does actually require work, which might conceivably= =20 matter at scale?). I'm not sure why one would not include P in the measure? Even an explicit multisig that does not sacrifice control of the output=20 would be of the order of double the embedding rate, without having to do=20 work. (P,R,s x 2 =3D 192 and embed 32 for a 1/6 rate; vs. grinding all 4 P,= R=20 values for a 1/12 rate). On Thursday, October 2, 2025 at 6:59:41=E2=80=AFPM UTC-3 Greg Maxwell wrote= : > I just meant in the purely grinding non-key leaking case you could get 4= =20 > bytes into the nonce pretty easily and 4 bytes into either the pubkey or= =20 > signature out of a 64 byte signature. Obviously the delivered embedding= =20 > rate in a whole txn will be lower, but maybe not that much thanks to=20 > multisig outputs. > > > On Thu, Oct 2, 2025 at 4:17=E2=80=AFPM waxwing/ AdamISZ wrote: > >> > > 12% embedding rate >> > Where do you get that number from? 33% for embedding 256 bits in (P, R= ,=20 >> s) (but as per this discussion, according to me, at the cost of key=20 >> leakage). If we include the other bytes in a (taproot anyway) utxo that'= s=20 >> not much less, I guess 30% ish. I could try to guess but it'd be easier = if=20 >> you told me :) >> >> Thinking about it again: to publish data, you have to publish a=20 >> transaction! I guess the most economical, paying taproot to taproot, is= =20 >> about 192 bytes with script path plus the posited extra 64 for the (R,s)= in=20 >> the output, so yeah that'd be 32 out of 256, 12.5%. Isn't the figure a b= it=20 >> different for key path though, because no control block? Well it hardly= =20 >> matters, it's some small fraction in that range. >> >> An interesting mechanical detail in this near-absurd scenario is that if= =20 >> you wanted to repeatedly publish off the same (presumably a few multiple= s=20 >> of dust level) output, you couldn't also do the leak single key thing,= =20 >> since you'd lose control to re-spend. So that'd place us in the "explici= t=20 >> multisig" scenario that Greg mentioned, which I think would only make se= nse=20 >> with legacy script? Kind of a different scenario, also it would be reall= y=20 >> weird to update legacy script to take into account a new "you must sign = the=20 >> pubkeys" rule. Though I guess in this fictional scenario, it might happe= n=20 >> like that. If you did do it with legacy, you'd be publishing bare 2 of 2= =20 >> multisig. If you did it with taproot due to how that works, the script i= s=20 >> not published until the output is spent, so I think that's outside what = I=20 >> was considering ("data in utxo set"). (I guess you could also use someth= ing=20 >> like a hash lock which might be more efficient). So anyway if you wanted= to=20 >> do this repeatedly and minimize cost, for whatever strange reason, you'd= be=20 >> adding another 50-100 bytes each time bringing that % down to like 10% o= r=20 >> less. >> >> But that all became way too hypothetical to even analyze properly :) >> >> Anyway just to reemphasize I certainly wasn't advocating this=20 >> sig-attaching system, but it seems important to know what the result of = it=20 >> would be: we would still not have changed the obvious reality that=20 >> embedding data in witness gives more space for data, and is more=20 >> economical, and we would only reduce by a big factor how much can be=20 >> embedded in outputs (anything from 8% to 15% embedding rate seems possib= le=20 >> depending on the hypothetical details), while having to screw up much of= =20 >> Bitcoin's functionality in the process. >> >> Cheers, >> AdamISZ/waxwing >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/cf15c24e-18d0-4221-a3d4-417= 7c82a6381n%40googlegroups.com=20 >> >> . >> > --=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/= b486e5dd-d5b4-43f1-9d9a-20b772d3dc1bn%40googlegroups.com. ------=_Part_201425_620897329.1759755886831 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, sorry, reading fail on my part (somehow missed that you were explicitl= y referring to grinding in the comment).

Still don't t= hink the 12% figure is a good one though? in (P,R,s) it's 8 out of 96 (and = as discussed, worse if whole tx is (realistically) included), 1/4 the rate = you get from direct key leakage. (Plus the perhaps trivial point that it do= es actually require work, which might conceivably matter at scale?). I'm no= t sure why one would not include P in the measure?

Even an explicit multisig that does not sacrifice control of the output = would be of the order of double the embedding rate, without having to do wo= rk. (P,R,s x 2 =3D 192 and embed 32 for a 1/6 rate; vs. grinding all 4 P,R = values for a 1/12 rate).



On Thursday, O= ctober 2, 2025 at 6:59:41=E2=80=AFPM UTC-3 Greg Maxwell wrote:
I j= ust 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 signatu= re 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 o= utputs.


On Thu, Oct 2,= 2025 at 4:17=E2=80=AFPM waxwing/ AdamISZ <ekag...@gmail.com> wrote:
> >= =C2=A0=C2=A012% embedding rate
> Where do you get that number from? = 33% for embedding 256 bits in (P, R, s) (but as per this discussion, accord= ing 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 tr= y to guess=C2=A0but it'd be easier if you told me :)

Thinking about it again: to publish data, you have to publish a tran= saction! I guess the most economical, paying taproot to taproot, is about 1= 92 bytes with script path plus the posited extra 64 for the (R,s) in the ou= tput, 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 m= atters, 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 o= f dust level) output, you couldn't also do the leak single key thing, s= ince you'd lose control to re-spend. So that'd place us in the &quo= t;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 &q= uot;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 th= ink 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 mo= re efficient). So anyway if you wanted to do this repeatedly and minimize c= ost, 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 advo= cating this sig-attaching system, but it seems important to know what the r= esult of it would be: we would still not have changed the obvious reality t= hat embedding data in witness gives more space for data, and is more econom= ical, 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,
Ad= amISZ/waxwing

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/cf15c24e-18d0-4221-a3d4-4177c82a638= 1n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/b486e5dd-d5b4-43f1-9d9a-20b772d3dc1bn%40googlegroups.com.
------=_Part_201425_620897329.1759755886831-- ------=_Part_201424_1075981190.1759755886831--