From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 08 Oct 2025 06:49:11 -0700 Received: from mail-yx1-f61.google.com ([74.125.224.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v6UXW-0003xV-Uh for bitcoindev@gnusha.org; Wed, 08 Oct 2025 06:49:11 -0700 Received: by mail-yx1-f61.google.com with SMTP id 956f58d0204a3-6354e48e9f1sf9322104d50.1 for ; Wed, 08 Oct 2025 06:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1759931345; x=1760536145; 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=kD9PRJoZ5kcRZpzJtCwlbvKqTtd0sTy6TEAUz4CWC1k=; b=lEASOkpTJ2HPJcAcnMofUG9LUn+MVz4rtac+1v3Y4Ym6QHq1+KlP3qWnn9uMXmRUV4 wxmgX5vCaCHnawrbLOh1HcczdMQi+oWxUiCoiZCTWO+ul/aGBywLxBpeSPE3ZwzVTjKL cmOKSJVSiBB5dAy8VaK9hsQgocZEf+SPso/dQy2iQFpZ/628fPk0pxFyec0x9tql8QI9 MtyhGcnG0QOBbLCOgxchNHVc/3zbxJn3feCY4dcZ6K0VI5bqm9Y390poQ58OprdE3mQx h6TND8QbE6lbK3eBcyLsIT798r3eEepcaJ1OVnfN9dmLFW4s5wmXWKSCRHQnY/gZTcVv c8Gg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759931345; x=1760536145; 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=kD9PRJoZ5kcRZpzJtCwlbvKqTtd0sTy6TEAUz4CWC1k=; b=jewGbR+i2z5sLtylEFuv9NOFDXbWkHMx4JUeienBK96X4jJXJcvq/jziebiOxjE8pR oB3G17BZ5K95+GiskHcdTV1axCbexPHev5Iuh6p638mWsQRymO3gnniCWxltSBLTEa4P N5C8yHB1uOCgq87zIEDrvI+mCnuxiSIaD5jUBaO2lbvZw8pVseQ1q2SFHNoJDCJmYEer wWeG7ARUggVyaCm+XCvmXR8zsva0SMaJmg9ndsm1Faih1fdiHWbbc5ouHj4RF6qjr2f4 wD6vTq8BoogIAh1YsHCyDUFdjW6EdATb/VxKwhXYSdlRfm3jL2R22i8PCP76+sIZWufp shIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759931345; x=1760536145; 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=kD9PRJoZ5kcRZpzJtCwlbvKqTtd0sTy6TEAUz4CWC1k=; b=VwsBnqofCbvO/l0ULs++B/mMMP4JztHuHk6LuO1tkFTEPzsl3UUJmDiizpewC0GSut K8bfbfCnoV87BV72SRmpyGxRrDSUsPh0RGj9/y+gnM6Sgqwxv4sBE0zLM/r26DnY7RGW nmU3LMH2U9WL3DETXxvMOScwzBTbzVdUI0YpE+UABDy6Tq0LXxR/xgMG5jKcmAh55WJj jxXNsy7CofsrOXTxK1JWbdBy14KdGZLoszHe3EhpszfhRwtW4GYc9Lhy/IpFO6ZHoSc2 mSOa90ap27TrHIGOMSSv8ehP/cMRsBRxB9L2dT8SW6Tct+QRaEZ3Hchhmf59OPI9dXJR 8Npw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUorGcCfnNke9O6j5RvXHFmab2qF70p4+6tKR146VooHZg48s2Lei4eLvB9UEtLxF0R5MQhm9slAmne@gnusha.org X-Gm-Message-State: AOJu0YxhmWSQoPBPYxbknmQMWPNgMfmaacaMih2H2vOjmYR8Ko1vLR6D Cl2D7bNgJQNbqAr1nu5MNJniBpsf66opN4ZPD/1/BIYSdgUTy8FR+9Ab X-Google-Smtp-Source: AGHT+IEbok+xiK8QgxU03diNqApxJ3umYOwL9N2XPFqb9HX6YyUnoY+rFAQlMHo9cFOfxivtlRs7Fw== X-Received: by 2002:a05:690e:452:b0:63c:bee2:4ef0 with SMTP id 956f58d0204a3-63ccb8edf83mr2606284d50.39.1759931344572; Wed, 08 Oct 2025 06:49:04 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd5JcXS18pXLOsaODwf+PIon1LbJOIo1G1RX0HvD/dMyUQ==" Received: by 2002:a05:690e:158a:10b0:636:53a:b5f5 with SMTP id 956f58d0204a3-63b8385578als523495d50.0.-pod-prod-05-us; Wed, 08 Oct 2025 06:48:57 -0700 (PDT) X-Received: by 2002:a05:690c:88a:b0:731:8693:dfb7 with SMTP id 00721157ae682-780e1568225mr43964927b3.7.1759931337838; Wed, 08 Oct 2025 06:48:57 -0700 (PDT) Received: by 2002:a05:690c:62c2:b0:741:b7fe:46f4 with SMTP id 00721157ae682-780e27af742ms7b3; Wed, 8 Oct 2025 05:55:37 -0700 (PDT) X-Received: by 2002:a05:690c:260b:b0:77e:5cc9:9f32 with SMTP id 00721157ae682-780e160c6edmr43416407b3.23.1759928136836; Wed, 08 Oct 2025 05:55:36 -0700 (PDT) Date: Wed, 8 Oct 2025 05:55:36 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <323c2d13-e90f-49c5-bfe0-f161b8b8dbb4n@googlegroups.com> In-Reply-To: References: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.com> Subject: Re: [bitcoindev] On (in)ability to embed data into Schnorr MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_90610_1844959463.1759928136464" 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_90610_1844959463.1759928136464 Content-Type: multipart/alternative; boundary="----=_Part_90611_157368863.1759928136464" ------=_Part_90611_157368863.1759928136464 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Answers inline. On Wednesday, October 8, 2025 at 5:45:06=E2=80=AFAM UTC-3 Anthony Towns wro= te: On Tue, Oct 07, 2025 at 05:05:24AM -0700, waxwing/ AdamISZ wrote:=20 > Yes, basically. I discuss this in the paper w.r.t. ECDSA. Your=20 description=20 > of the relevance of pubkey recovery is good, but there are some nuances.= =20 > You can't quite (with ECDSA) get P to be the data and have a valid sig,= =20 but=20 > you can get 's' to be the data simply by backsolving for the private key= =20 x.=20 > Lack of "pubkey prefixing" in the very funky 'commitment to the nonce' in= =20 > ECDSA causes that. And the second nuance, you did actually mention: you= =20 get=20 > "not leaking the key" for free, here. But it's still only a 32/96 bytes= =20 > embedding rate though, the way I count it.=20 You've got 4x 32-byte values to play with: s, r, p and m. The verification= =20 equation determines one of these, reducing it to 3x. m isn't able to be=20 freely chosen, reducing it to 2x. And being able to reverse the equation=20 in order to calculate anything requires the receiver to know one of the=20 secrets, which reduces it to 1x. (Grinding can bump that back up to a=20 factor of 1.something) So that's the 32. On the other side, you need to=20 transmit everything but m which is otherwise determined by the setup,=20 so that's the 96.=20 Yeah I think so, roughly. It's not 100% watertight deductions but it seems= =20 correct from where I'm sitting. (I would only nit that 'm' isn't in consideration as it's implicit, not=20 published, in current signature usage; in a proposed signature-in-output, m= =20 would obviously be constrained to something with no wiggle room (and=20 including P if we used ECDSA, but we wouldn't). =20 > I think the logic of that is not quite right. Suppose I want to embed=20 > pictures into the unpruneable utxo set specifically (and not only 'in=20 > transactions').=20 Sure, but then I'll also suppose your goal is to harm Bitcoin by bloating= =20 the utxo set. If that weren't one of your fundamental goals, you'd use=20 other, cheaper and easier, ways of encoding the data. But the goal can be simply this: my data is more marketable if I can=20 plausibly claim that it's embedded into bitcoin nodes for eternity (whether= =20 true or not, it's marketable). AFAIK this is indeed a thing, in the real=20 world. =20 > Very nice example. I am glad you took the trouble to write it out,=20 because=20 > I agree that examples like that are worth working through because as you= =20 > say they lean closer to being properly indistinguishable from ordinary=20 > transaction patterns.=20 I think the (P,R,s) outputs could be an interesting design for a=20 non-programmable system that was intended purely for payments -- a=20 FEDwire/SWIFT replacement without the possibility of vaults, lightning,=20 etc. Presumably more mimblewimble friendly etc too. Presumably the "R,s"=20 values could also be a signature of P by the operator's well known pubkey,= =20 giving you a KYC/CBDC-like system too.=20 You could get programmability back in this scenario by allow P to sign=20 a script, which you then satisfy, rather than signing a payment directly=20 (ie, the graftroot approach).=20 I like this line of thought, and indeed I'd forgotten about graftroot and= =20 the whole delegation angle. (and just to repeat the point made earlier: we'd only need to sign over a= =20 message including P for ecdsa, but we wouldn't use that.) I guess if you're discussing a hypothetical permissioned system though it's= =20 a whole different world, so I'm going to sidestep that one. But it does sound interesting to do delegation and then ZkPOK outputs even= =20 in a Bitcoin world. Albeit it's a long way from where we are today. Of course we're firmly pie in the sky again here, but I think it helps=20 inform thinking about Bitcoin as it is concretely today. =20 Anyway, once you make the system programmable in interesting ways, I=20 think you get data embeddability pretty much immediately, My main motivation in discussing this was indeed the extent to which you=20 get embeddability even without any programmability; as we've established,= =20 it's not zero, and it's not restricted to grinding (exponential work). But= =20 in *pure* unprogrammable, ZkPOK outputs of form P, R,s and nothing else=20 allowed, it *is*, I'm claiming, restricted to key leakage and doesn't=20 surpass 33%. and then it's=20 just a matter of trading off the optimal encoding rate versus how easily=20 identifiable your transactions can be. Forcing data to be hidden at a=20 cost of making it less efficient just leaves less resources available=20 to other users of the system, though, which doesn't seem like a win in=20 any way to me.=20 > Your points about limits, standardness constraints are well taken; those= =20 > are the kinds of things that do actually matter today, but I was not=20 > thinking about.=20 Note that I mentioned the standardness constraints not because they're=20 limits today, but rather because they reflect the form existing txs take,= =20 so mimicing that form would allow txs embedding data via this scheme to=20 be difficult to distinguish from other txs, and hence equally difficult=20 to censor/filter.=20 I see. Good point. =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/= 323c2d13-e90f-49c5-bfe0-f161b8b8dbb4n%40googlegroups.com. ------=_Part_90611_157368863.1759928136464 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Answers inline.

On Wednesday, October 8, = 2025 at 5:45:06=E2=80=AFAM UTC-3 Anthony Towns wrote:
On Tue, Oct 07, 2025 at 05:05:24AM -0700, waxwing= / AdamISZ wrote:
> Yes, basically. I discuss this in the paper w.r.t. ECDSA. Your d= escription
> of the relevance of pubkey recovery is good, but there are some = nuances.
> You can't quite (with ECDSA) get P to be the data and have a val= id sig, but
> you can get 's' to be the data simply by backsolving for the pri= vate key x.
> Lack of "pubkey prefixing" in the very funky 'commitment to the = nonce' in
> ECDSA causes that. And the second nuance, you did actually menti= on: you get
> "not leaking the key" for free, here. But it's still only a 32/9= 6 bytes
> embedding rate though, the way I count it.

You've got 4x 32-byte values to play with: s, r, p and m. The verific= ation
equation determines one of these, reducing it to 3x. m isn't able to = be
freely chosen, reducing it to 2x. And being able to reverse the equat= ion
in order to calculate anything requires the receiver to know one of t= he
secrets, which reduces it to 1x. (Grinding can bump that back up to a
factor of 1.something) So that's the 32. On the other side, you need = to
transmit everything but m which is otherwise determined by the setup,
so that's the 96.

Yeah I think so, roughly. It's not 100% watertight = deductions but it seems correct from where I'm sitting.
(I would = only nit that 'm' isn't in consideration as it's implicit, not published, i= n current signature usage; in a proposed signature-in-output, m would obvio= usly be constrained to something with no wiggle room (and including P if we= used ECDSA, but we wouldn't).
=C2=A0
> I think the logic of that is not quite right. Suppose I = want to embed
> pictures into the unpruneable utxo set specifically (and not onl= y 'in
> transactions').

Sure, but then I'll also suppose your goal is to harm Bitcoin by bloa= ting
the utxo set. If that weren't one of your fundamental goals, you'd us= e
other, cheaper and easier, ways of encoding the data.

But the goal can be simply this: my data is more marketa= ble if I can plausibly claim that it's embedded into bitcoin nodes for eter= nity (whether true or not, it's marketable). AFAIK this is indeed a thing, = in the real world.
=C2=A0
values could also be a signature of P by the operator's well known pu= bkey,
giving you a KYC/CBDC-like system too.

You could get programmability back in this scenario by allow P to sig= n
a script, which you then satisfy, rather than signing a payment direc= tly
(ie, the graftroot approach).


I like this line of thought, and i= ndeed I'd forgotten about graftroot and the whole delegation angle.
(and just to repeat the point made earlier: we'd only need to sign over = a message including P for ecdsa, but we wouldn't use that.)
I gue= ss if you're discussing a hypothetical permissioned system though it's a wh= ole different world, so I'm going to sidestep that one.

But it does sound interesting to do delegation and then ZkPOK outpu= ts even in a Bitcoin world. Albeit it's a long way from where we are today.=

Of course we're firmly pie in the sky again her= e, but I think it helps inform thinking about Bitcoin as it is concretely t= oday.
=C2=A0
Anyway, onc= e you make the system programmable in interesting ways, I
think you get data embeddability pretty much immediately,

My main motivation in discussing this was indeed the= extent to which you get embeddability even without any programmability; as= we've established, it's not zero, and it's not restricted to grinding (exp= onential work). But in *pure* unprogrammable, ZkPOK outputs of form P, R,s = and nothing else allowed, it *is*, I'm claiming, restricted to key leakage = and doesn't surpass 33%.

and then it's
just a matter of trading off the optimal encoding rate versus how eas= ily
identifiable your transactions can be. Forcing data to be hidden at a
cost of making it less efficient just leaves less resources available
to other users of the system, though, which doesn't seem like a win i= n
any way to me.

> Your points about limits, standardness constraints are well take= n; those
> are the kinds of things that do actually matter today, but I was= not
> thinking about.

Note that I mentioned the standardness constraints not because they'r= e
limits today, but rather because they reflect the form existing txs t= ake,
so mimicing that form would allow txs embedding data via this scheme = to
be difficult to distinguish from other txs, and hence equally difficu= lt
to censor/filter.

I see. Good point.
=C2=A0

--
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/323c2d13-e90f-49c5-bfe0-f161b8b8dbb4n%40googlegroups.com.
------=_Part_90611_157368863.1759928136464-- ------=_Part_90610_1844959463.1759928136464--