From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 25 May 2025 08:57:55 -0700 Received: from mail-yw1-f190.google.com ([209.85.128.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uJDjW-0002oD-0b for bitcoindev@gnusha.org; Sun, 25 May 2025 08:57:55 -0700 Received: by mail-yw1-f190.google.com with SMTP id 00721157ae682-708b13627absf23763377b3.2 for ; Sun, 25 May 2025 08:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1748188668; x=1748793468; 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=VjkoCmRUKQShFm44ZatHlNE3zacidOsAaDwuAAkJKew=; b=rYr/J5SGrnpJmkRwgw/3+LT2+DVjZLeqkvccFkVMeJj/C5MkUqwC41V+6NjWbK1ccm JuIwe/o31mrN1vUIQQCi2XULkW6hkggfuThzj1TiNkKAVs2Ke6610OI7CdFVZRl+LSkK +iNgPcDgv9L3RcTL34+pFvhKRlYLOeTdCvEKK7j1sucx6B5nzdGAcC96QLlCREND5p9N Bhaa+B8b59g7yeH3dNgBAqsFAfqSipxlEHgGPeRmw2G+OCKUCzYOf4rY+uqFu0zzYvZt e8hKsjuotnf4D151o06pqZVsBsl+iBeu6epeGS6lX5g4e5cvbn0qAzFark5irBNOpfj1 LG8w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748188668; x=1748793468; 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=VjkoCmRUKQShFm44ZatHlNE3zacidOsAaDwuAAkJKew=; b=Kd2i0NTuoFBzesauqKme4ya47JS8EUqUwNZT5ep7CY/ZzcKUL5tEo0hHf4PqHLmkBA tHuJQffb+UzZeTXhYZQBCQR3LQOOezyIngA27yhbnLMfkUEuSw7DH0cfTHTkbZjCXIeO SGDnyq0czk9160fV7Zf/bM7KrPbejJKIxTLKc1Wbm9ju3ZQ+jcrRQ1NUDHwCLIPHlagN JeovfL4MUrRKrD0chPtr8/LLZ7UP7G9H0NYdz5T7YHgUECMt0MMlqEQ1hzMJU5EaQGMc 36+yLjj0ZcdOFvssZCCl4wVL5yPCVrdiFk8bPrrqO/iKRyWMEOxyib9PvWFKXc4LoYzt RDTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748188668; x=1748793468; 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=VjkoCmRUKQShFm44ZatHlNE3zacidOsAaDwuAAkJKew=; b=QDhgMVI9Ll5il2GjQwdfFrLyIqmLkY6H+DDzoJjpL+YU4wil7pEHQuDwky7nwJ0Vo3 pwCFsYcD9URMJMA+d4SrII14TaZwC1cJzpgx3dYrI6puFaaKwLwLZcmCudWmNf5B2HAZ Fm7LvSaxKj2Sm8fxv/3uJ+u0VBlH3b6o7/u/2LwMK0mbvP2gj24lJfynx1Jv5zq+UbQc T1mLAX/cTGMGGrjS0/38viqSedbBGhpfVfg/mWPz/elVxzLg4ZPICnm8xVrtZTOMXSBY mr7udqvsaclg/1RvR1ausSo94eoQlLAOB+8n3r9WSOwtp4Djcm42c4z5JzA7jV3VvENB ClxA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWA6d9TAVOlfkXmw/bzr9Ei5aEuvAqMF7bG83vRpht8QBlMSu2xZiaG90vEsXED2xmsZ1QrXy0spA1Z@gnusha.org X-Gm-Message-State: AOJu0YwsU25IA9mlad8SLRSdVg+8J8mIcaNhk7PN7/EmThOxq0J11EvP Au6c3l1deiS2bW2/R5U9hpqQFmBGkIf1FXgehYc8Bec+7Ecjo0/nHdEm X-Google-Smtp-Source: AGHT+IERCQ8DS8CSfa3S3TymNCqw0r4hEJAhdNKIuzurqVYR+EnV/5o+EeoAGgqfvmnja5SC8C4gDw== X-Received: by 2002:a05:6902:c10:b0:e7d:6a8e:dc5a with SMTP id 3f1490d57ef6-e7d91d60db0mr5640875276.36.1748188668107; Sun, 25 May 2025 08:57:48 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBFUB5TClt0RXVz/AwAJ0SUjsL63sJzv/oyPlEujD6304A== Received: by 2002:a25:dc81:0:b0:e7d:804c:d381 with SMTP id 3f1490d57ef6-e7d92192110ls1322013276.2.-pod-prod-00-us; Sun, 25 May 2025 08:57:44 -0700 (PDT) X-Received: by 2002:a05:690c:6210:b0:70d:8e1f:ec2b with SMTP id 00721157ae682-70e18510e19mr111313607b3.6.1748188663931; Sun, 25 May 2025 08:57:43 -0700 (PDT) Received: by 2002:a0d:de45:0:b0:70e:3f3a:2c12 with SMTP id 00721157ae682-70e3f3a344dms7b3; Sun, 25 May 2025 08:53:27 -0700 (PDT) X-Received: by 2002:a05:690c:45c5:b0:70c:9a57:699e with SMTP id 00721157ae682-70e18524589mr113212717b3.7.1748188406576; Sun, 25 May 2025 08:53:26 -0700 (PDT) Date: Sun, 25 May 2025 08:53:26 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com> References: <16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com> Subject: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_29330_1618525221.1748188406236" 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_29330_1618525221.1748188406236 Content-Type: multipart/alternative; boundary="----=_Part_29331_1777088072.1748188406236" ------=_Part_29331_1777088072.1748188406236 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, list, re: > A point of clarification, that's really a scheme to keep arbitrary data= =20 out of unprunable data. The proofs that the values in question are what=20 they're supposed to be are themselves arbitrary data channels. But these= =20 proofs are prunable. Could you expand on the "arbitrary data channels" here? I was thinking through specifically the case of (pre-taproot) raw pubkey=20 outputs and thinking about what it would mean to prove that it's not data;= =20 here, the obvious approach is "ECDSA-sign using the key" which trivially=20 fails to prove it's not data if the message for the signature is=20 unconstrained. But obviously, it would be constrained to be e.g. the hash= =20 of the pubkey, fixing it and preventing data storage in the (s) component= =20 of ECDSA's (r, s). (i.e. if you wanted to bypass this scheme to still store= =20 32 bytes of data, you'd just choose s as that data and then use the=20 standard pubkey recovery algorithm; except you can't if P is in the=20 message). All of that seems spectacularly irrelevant, not only because trivially you= =20 avoid it with using Hash(P) in the sig message, but even more, since this= =20 would be a new piece of consensus, you could just use BIP340 or any similar= =20 Schnorr with key-prefixing anyway, no matter what style of scriptPubKey is= =20 involved. The question is, what is the arbitrary data channel that you refer to, that= =20 remains, when doing this? The R-value is ofc arbitrary but it's still a=20 "image" not "preimage" (x-coord for the nonce secret * G). As I write this,= =20 one answer occurs to me, that if you used the same R value twice you leak= =20 the nonce and the secret key, which in this weird setup means you are=20 "broadcasting" 2 32 byte values that are random, in 2 outputs, which I=20 guess is the same embedding ratio? A horrible idea in practice given you=20 lose control of the outputs; I know that at least some schemes that embed= =20 data in utxos deliberately do so to keep them in the utxo set permanently.= =20 So I somehow feel that that's not what you meant ... Cheers, AdamISZ/waxwing On Friday, May 2, 2025 at 9:00:25=E2=80=AFPM UTC-3 Greg Maxwell wrote: > On Friday, May 2, 2025 at 10:23:45=E2=80=AFPM UTC Peter Todd wrote: > > # _Uninterrupted_ Illicit Data=20 > > > To refine that, _illicit data_ is a problem and encryption at rest does= =20 > not address particularly in so far as possession of some data is a strict= =20 > liability crime. > > Uninterrupted however means that it's more likely to get caught by random= =20 > scanning tools and whatnot -- and the encryption does that and probably= =20 > eliminates most of difference between interrupted and not, which is Peter= =20 > Todd's point. > > But I heard someone last night say that encryption solves the illicit dat= a=20 > issue and it absolutely doesn't. It solves a particular unexciting but mo= re=20 > immediate sub part of the problem which is stuff like AV scanners. But I= =20 > think that issue is orthogonal to this proposed change. > > Aside, I'd been thinking there was a consensus limit on output sizes of= =20 > 10kb but now I'm remembering that it's just at spend time and so obviousl= y=20 > wouldn't be relevant here. > =20 > > to make data publication somewhat more expensive with consensus changes.= =20 > Gregory Maxwell outlined how to do so on this mailing list years ago=20 > > > A point of clarification, that's really a scheme to keep arbitrary data= =20 > out of unprunable data. The proofs that the values in question are what= =20 > they're supposed to be are themselves arbitrary data channels. But these= =20 > proofs are prunable. > > It's true that they they only need to be carried near the tip, so you=20 > could even consider them *super prunable*. And while perhaps you can ge= t=20 > many existing transaction patterns into that model, I'm pretty confident= =20 > you can't eliminate high bandwidth channels in script without massively= =20 > hobbling Bitcoin overall. (Though hey, there are a lot of people out the= re=20 > these days who would like to hobble bitcoin, so ::shrugs::) =20 > > Even if the functionality reduction were worth it, I dunno that the gain= =20 > between prunable (where most data storage stuff is) and super-prunable is= =20 > that interesting, particularly since you're looking at on the order of a= =20 > 20%-30% increase of bandwidth for transactions and blocks to carry those= =20 > proofs. Though for context I then eventually most nodes will sync throug= h=20 > some kind of utxo fast forward, just due to practical considerations, and= =20 > w/ that the difference in prunability degree is diminished further. > > It might make sense for just *outputs* if data stuffing into the UTXO set= =20 > continues to be a problem as I think it can be done for just outputs=20 > without huge functionality loss... though even so the disruption and=20 > overheads yuck. But before even considering such a disruptive change you= 'd=20 > want to be really user everything was done to get the storage out of the= =20 > unprunable data first, e.g. by getting rid of limits on op_return size. > > have an overhead of about 6.6x. Existing data encoders have been happy=20 > to pay even more money than that in terms of increased fees during fee=20 > spikes; the difference in cost between witness space and txout space is= =20 > already 4x, and some are happy to publish data that way anyway.=20 > > > A point I raised on bitcointalk: If you work out how much it costs to=20 > store data on S3 (by far not the cheapest internet data storage) for=20 > *forever* you end up with a rate that is less than a hundred thousandth t= he=20 > current Bitcoin minimum fee rate-- maybe way less if you also factor in t= he=20 > cost of storage decreasing, but I didn't. Data stuffers are not=20 > particularly price sensitive, if they were they wouldn't be using Bitcoin= =20 > at all. Schemes to discourage them by causing them increased costs (e.g.= =20 > by forcing them to encode in ways that use more block capacity) shouldn't= =20 > be expected to work. > > And to the extent that what many of these things have been doing is tryin= g=20 > to profit off seigniorage-- creating a rare 'asset' to sell to some great= er=20 > fool and profit off the difference-- further restricting them could=20 > increase their volume because the resource they need has been made more= =20 > rare. For the vast majority of users the ire comes about this stuff from= =20 > the fact that they've driven up fees at times, but that is dependent on= =20 > what they're willing to spend, which is likely not particularly related t= o=20 > the marginal data rates. (And one could always embed smaller jpegs,=20 > compress them better, or not use raw json instead of an efficient encodin= g=20 > if they cared.. which they clearly don't.) > > --=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/= bd2c8cd1-69bc-4ffc-9ff4-fa12e929c2afn%40googlegroups.com. ------=_Part_29331_1777088072.1748188406236 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg, list,

re:

> A point of clarification,=C2=A0 that's really a scheme to keep arbi= trary data out of unprunable data.=C2=A0 The proofs that the values in question are= =20 what they're supposed to be are themselves arbitrary data channels.=C2=A0 B= ut these proofs are prunable.

Could you expand on = the "arbitrary data channels" here?

I was thinki= ng through specifically the case of (pre-taproot) raw pubkey outputs and th= inking about what it would mean to prove that it's not data; here, the obvi= ous approach is "ECDSA-sign using the key" which trivially fails to prove i= t's not data if the message for the signature is unconstrained. But obvious= ly, it would be constrained to be e.g. the hash of the pubkey, fixing it an= d preventing data storage in the (s) component of ECDSA's (r, s). (i.e. if = you wanted to bypass this scheme to still store 32 bytes of data, you'd jus= t choose s as that data and then use the standard pubkey recovery algorithm= ; except you can't if P is in the message).

All = of that seems spectacularly irrelevant, not only because trivially you avoi= d it with using Hash(P) in the sig message, but even more, since this would= be a new piece of consensus, you could just use BIP340 or any similar Schn= orr with key-prefixing anyway, no matter what style of scriptPubKey is invo= lved.

The question is, what is the arbitrary dat= a channel that you refer to, that remains, when doing this? The R-value is = ofc arbitrary but it's still a "image" not "preimage" (x-coord for the nonc= e secret * G). As I write this, one answer occurs to me, that if you used t= he same R value twice you leak the nonce and the secret key, which in this = weird setup means you are "broadcasting" 2 32 byte values that are random, = in 2 outputs, which I guess is the same embedding ratio? A horrible idea in= practice given you lose control of the outputs; I know that at least some = schemes that embed data in utxos deliberately do so to keep them in the utx= o set permanently. So I somehow feel that that's not what you meant ...

Cheers,
AdamISZ/waxwing

On Friday, May = 2, 2025 at 9:00:25=E2=80=AFPM UTC-3 Greg Maxwell wrote:
On Friday= , May 2, 2025 at 10:23:45=E2=80=AFPM UTC Peter Todd wrote:
# _Uninterrupted_ Illicit Data

To refine that, _illicit data_ is a pr= oblem and encryption at rest does not address particularly in so far as pos= session of some data is a strict liability crime.

= Uninterrupted however means that it's more likely to get caught by rand= om scanning tools and whatnot -- and the encryption does that and probably = eliminates most of difference between interrupted and not, which is Peter T= odd's point.

But I heard someone last night sa= y that encryption solves the illicit data issue and it absolutely doesn'= ;t. It solves a particular unexciting but more immediate sub part of the pr= oblem which is stuff like AV scanners.=C2=A0 But I think that issue is orth= ogonal to this proposed change.

Aside, I'd bee= n thinking there was a consensus limit on output sizes of 10kb but now I= 9;m remembering that it's just at spend time and so obviously wouldn= 9;t be relevant here.
=C2=A0
to make data publication somewhat more expensive with consensus cha= nges.
Gregory Maxwell outlined how to do so on this mailing list years ago

A point of clarification,= =C2=A0 that's really a scheme to keep arbitrary data out of unprunable = data.=C2=A0 The proofs that the values in question are what they're sup= posed to be are themselves arbitrary data channels.=C2=A0 But these proofs = are prunable.

It's true that they they only ne= ed to be carried near the tip, so you could even consider them *super pruna= ble*.=C2=A0=C2=A0 And while perhaps you can get many existing transaction p= atterns into that model, I'm pretty confident you can't eliminate h= igh bandwidth channels in script without massively hobbling Bitcoin overall= .=C2=A0 (Though hey, there are a lot of people out there these days who wou= ld like to hobble bitcoin, so ::shrugs::)=C2=A0

Even if the functionality reduction were worth it, I dunno that the gain= between prunable (where most data storage stuff is) and super-prunable is = that interesting, particularly since you're looking at on the order of = a 20%-30% increase of bandwidth for transactions and blocks to carry those = proofs.=C2=A0 Though for context I then eventually most nodes will sync thr= ough some kind of utxo fast forward, just due to practical considerations, = and w/ that the difference in prunability degree is diminished further.

It might make sense for just *outputs* if data stuffi= ng into the UTXO set continues to be a problem as I think it can be done fo= r just outputs without huge functionality loss... though even so the disrup= tion and overheads yuck.=C2=A0 But before even considering such a disruptiv= e change you'd want to be really user everything was done to get the st= orage out of the unprunable data first, e.g. by getting rid of limits on op= _return size.

ha= ve an overhead of about 6.6x. Existing data encoders have been happy
to pay even more money than that in terms of increased fees during fee
spikes; the difference in cost between witness space and txout space is
already 4x, and some are happy to publish data that way anyway.

A point I raised on bitcoin= talk: If you work out how much it costs to store data on S3 (by far not the= cheapest internet data storage) for *forever* you end up with a rate that = is less than a hundred thousandth the current Bitcoin minimum fee rate-- ma= ybe way less if you also factor in the cost of storage decreasing, but I di= dn't.=C2=A0 Data stuffers are not particularly price sensitive, if they= were they wouldn't be using Bitcoin at all.=C2=A0 Schemes to discourag= e them by causing them increased costs (e.g. by forcing them to encode in w= ays that use more block capacity) shouldn't be expected to work.
<= div>
And to the extent that what many of these things have be= en doing is trying to profit off seigniorage-- creating a rare 'asset&#= 39; to sell to some greater fool and profit off the difference-- further re= stricting them could increase their volume because the resource they need h= as been made more rare.=C2=A0 For the vast majority of users the ire comes = about this stuff from the fact that they've driven up fees at times, bu= t that is dependent on what they're willing to spend, which is likely n= ot particularly related to the marginal data rates. (And one could always e= mbed smaller jpegs, compress them better, or not use raw json instead of an= efficient encoding if they cared.. which they clearly don't.)

--
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/bd2c8cd1-69bc-4ffc-9ff4-fa12e929c2afn%40googlegroups.com.
------=_Part_29331_1777088072.1748188406236-- ------=_Part_29330_1618525221.1748188406236--