From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 01 May 2025 11:08:16 -0700 Received: from mail-yb1-f185.google.com ([209.85.219.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uAYKU-0007Lf-3U for bitcoindev@gnusha.org; Thu, 01 May 2025 11:08:16 -0700 Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-e72ced90ffdsf1735206276.0 for ; Thu, 01 May 2025 11:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1746122888; x=1746727688; 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=WXAU+3tLR2rqvIvDGi6ctLUoUpYoxHyz8wU9hoNECfg=; b=OBBhrYaoYz5zo0Lk8WEHyy8Hlurc1kFNEOMnXaD8JxKuyWvF8bxaRqtVAn5yhHHvMM affuiJ/J202UcKjMpv+ts1FaB67Jryc1wVVFRaaYsbJl6KuLWHx4stfr615t69oKd0eR W0aULJtgdEUeW/cXyCfKRIW2EzgNZ8vjJ6OcuMxaHOIhs/AF3Qh5y81XEes+5k7L+67k /RZtSqbdnGhM7KUzRRKi9IOOUO8ehQS9TRV/IibrD4+r6Zkov9XQrr6ktDc1Ogczt3D1 vSPvcfwa5S6NdvWBkr2fImzjhSxWTYezHLrlsPbeaQY9bLa3YYlP10Xx4J+pl/Eh8Z0g tmyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746122888; x=1746727688; 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=WXAU+3tLR2rqvIvDGi6ctLUoUpYoxHyz8wU9hoNECfg=; b=c9WJTX/FfAKXpDZ/+D2xD4LClw4c2exCBL9EsYAMYzZz3PnAKBHT9HSPCJT/KaTJeJ tcgTGs8mNI26Mp52G887IffVZ8lPsgxg9oxD3PE3DSp4n/Q5RdesNfulHPTU7FRyhp7B BteXLRnIaDLJd2kLXG5Vju5WyOHJIDZ3dhz1KhzsW1qPNctg3SW81Eh8yhfLx/jPdgoj rtllxEb9PA3GoMIDFQvgw+OB5t0Hl1BaBw8XgUrX+y/mgQvXl0ft9kk31Az8HAKTkLCG MwmY3SxtRP3TZKeUrkrEhfnYUeTusMax081KIMpCHy+iLGxtsUZlmcBkC+HSHmrhooPO ZeUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746122888; x=1746727688; 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=WXAU+3tLR2rqvIvDGi6ctLUoUpYoxHyz8wU9hoNECfg=; b=eeNfB5aWicoMdAnPHL3rrmp/ILjwy/EKpBbVYj7zhaD7MAoIxUASiKTQcJknVidoyj 2li1rjqe4WHDnFzCn+rcWFt0icaqpiXuA2Z7l4qcUvxOXJdguZneplPxKBuNHM31Kr1v FbYxVYzCI++jLHtOpgVcm5DbRzSeUfREz/uy9YpdPzcUW+JM4ewR8QCZQy+o+VvFaJ1c I6LHQD1xMRqiA+b2wcvqiObEwmHyRSyabHtlau5MK4XGSSJoq43iO6Xfpw9zdx/QMStJ 7VdQyVkgRrkynS7VQKyBD1/2+0yMo0veh/eO2iSbr89ZmkvIV0k1Xab2bV7g/FrBvItw Yi6A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXMl9LOBnobcsOs8aKyIgPGPEzBlkdXpz4VW5qlmGQbdUyYlorT13zVXnzlAel4YOOFauh3/tP9On6f@gnusha.org X-Gm-Message-State: AOJu0YxX0Nzfvy+qDC6N40RPTmE3oxtk8CT/lh/ml+WTY2vRT3NE+uf8 58D6tbdxemMl3oHro5qfCVdQGIry07Yxy5iiJx7ZVWyB0XNu7o4A X-Google-Smtp-Source: AGHT+IFHD+eT2cOGAiAChrDXePmxZ92NB0CY4PzUycs6+LE/Q+ElKKlfxeD5aqrcUgWJOicyPs21OQ== X-Received: by 2002:a05:6902:a09:b0:e72:ba52:87f5 with SMTP id 3f1490d57ef6-e756555811emr62269276.15.1746122887957; Thu, 01 May 2025 11:08:07 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBGMNJUYaqhkhMLUaf6tiBYc4aEp8XgGhzUhDjj09SMCsA== Received: by 2002:a25:2941:0:b0:e74:29b5:5ab2 with SMTP id 3f1490d57ef6-e74dc1e6bf2ls614450276.1.-pod-prod-03-us; Thu, 01 May 2025 11:08:04 -0700 (PDT) X-Received: by 2002:a05:690c:4884:b0:6ef:77e3:efe6 with SMTP id 00721157ae682-708ced45653mr4680417b3.13.1746122884335; Thu, 01 May 2025 11:08:04 -0700 (PDT) Received: by 2002:a81:ee08:0:b0:708:1ea1:3cd5 with SMTP id 00721157ae682-708bca3a47ams7b3; Thu, 1 May 2025 10:40:17 -0700 (PDT) X-Received: by 2002:a05:690c:4884:b0:6ef:77e3:efe6 with SMTP id 00721157ae682-708ced45653mr2909447b3.13.1746121216319; Thu, 01 May 2025 10:40:16 -0700 (PDT) Date: Thu, 1 May 2025 10:40:15 -0700 (PDT) From: Andrew Toth To: Bitcoin Development Mailing List Message-Id: <1e353962-1665-4bc5-8a35-e349fdf4832cn@googlegroups.com> In-Reply-To: References: <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org> Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_75092_1221089082.1746121215961" X-Original-Sender: andrewstoth@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_75092_1221089082.1746121215961 Content-Type: multipart/alternative; boundary="----=_Part_75093_1872975406.1746121215961" ------=_Part_75093_1872975406.1746121215961 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW I've written a tool to xor your blocks dir without having to resync.= =20 https://github.com/andrewtoth/blocks-xor/ On Thursday, May 1, 2025 at 5:24:22=E2=80=AFAM UTC-4 Jason Hughes wrote: > I believe you greatly overestimate the skill and competence of the people= =20 > who would do this type of thing. You could accomplish what you've laid ou= t.=20 > I could accomplish it. But the people who will actually do this to Bitcoi= n=20 > once there's unrestricted OP_RETURN likely can not accomplish it today.= =20 > What you've laid out is a more technical attack than this variant of atta= ck=20 > is capable of... and what will actually happen is that once unlimited=20 > OP_RETURN is a thing, people willing to, but not currently able, will tak= e=20 > the easy route for such attacks after someone with technical knowledge=20 > makes the "Connect your wallet, upload your data" button for them. > > All of that said, you make excellent points for ridding Bitcoin of=20 > arbitrary data completely. :) > > On Tue, Apr 29, 2025 at 3:20=E2=80=AFPM Martin Habov=C5=A1tiak =20 > wrote: > >> Hi, >> >> I have a little demo for you. >> >> Firstly, I think the kind of illegal content most people have in mind ar= e=20 >> images. So let's start with a question: if one takes an illegal picture = and=20 >> sets every 173th pixel to a red dot will it become legal? >> >> If you have trouble imagining it, here's an example for you:=20 >> https://imgur.com/a/J7RTPL7 >> >> If you believe it would, we can end this conversation and my point is=20 >> moot. >> However, I think you'll agree the image would still be illegal. >> >> Next, I think it's obvious that an attacker seeking to harm bitcoin user= s=20 >> would choose an any image format he likes. So for this example I'm picki= ng=20 >> BMP. >> >> If you encode the image above to BMP, which is uncompressed, the red=20 >> pixels turn into bytes 253, 7, 2 which happen to encode witness element= =20 >> length 519. The header size is 54 bytes, so stick the byte 54 at the fro= nt=20 >> and you have a valid serialization of a sequence of witness elements. >> >> Do you see what this means? >> >> >> ... >> >> >> Yes, it's too late to fix this. It's already trivially possible to make= =20 >> your node store a sequence of bytes that is considered illegal. If you'r= e=20 >> worried about it you have to resync the chain right now. >> >> Disclaimer: the numbers above might be a bit off, I did most computation= =20 >> in my head. Still, the point stands even if the pixels have a bit differ= ent=20 >> spacing/color. >> >> Same thing with malware distribution, except you can easily skip the=20 >> invalid bytes using jump instructions or other techniques, so that might= be=20 >> even worse. >> >> Happy syncing! >> >> Martin >> >> >> D=C5=88a ut 29. 4. 2025, 11:15 Jason Hughes (wk057) = =20 >> nap=C3=ADsal(a): >> >>> I was asked to take my comments to the mailing list, so here we go. >>> >>> First, see my comments on Github PR #32359: >>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933 >>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638919 >>> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756 >>> >>> Next, I'll once again point out relevant history for those just tuning= =20 >>> in: >>> >>> OP_RETURN was only made standard in a limited size to encourage less=20 >>> harmful data carrying in Bitcoin. Attackers were using harmful methods = of=20 >>> data carrying in unspendable UTXOs, and so a way to inject a small amou= nt=20 >>> of data was TOLERABLE over this harmful UTXO bloat that. That mostly= =20 >>> worked, and such practices were quickly minimized. This remained the ca= se=20 >>> for about a decade without significant issue. Bitcoin is not file stora= ge,=20 >>> and this was known to developers at that time. Sadly, eventually an=20 >>> exploit called 'inscriptions' happened which blew the cap off of the si= ze=20 >>> limitation of arbitrary data storage... and to make matters worse,=20 >>> developers refused to patch the exploit or otherwise enforce the decade= old=20 >>> limit on arbitrary data size. If that wasn't bad enough, exploiters get= a=20 >>> 75% discount on transaction fees. >>> >>> With that history in mind, removing limits on OP_RETURN standardness=20 >>> size is pointless. Relaxing OP_RETURN size limits without dealing with = the=20 >>> inscriptions exploit means no one will use this for anything besides=20 >>> attacking the network with the worst possible data. There's little to n= o=20 >>> incentive to use OP_RETURN for data storage when using the 'inscription= s'=20 >>> exploit costs 4x less in transactions. What's the point of having a=20 >>> "standard" way to store arbitrary data if the exploit method is 4x chea= per?=20 >>> And the nonstandard version of the exploit allows 4x the data? >>> >>> Further, the inscriptions exploit currently requires chunking the data= =20 >>> between PUSH opcodes, meaning an on-disk analysis doesn't actually dire= ctly=20 >>> reveal the underlying data the injector intended. I can still run=20 >>> something like "photorec" on my system and not have to sift through=20 >>> thousands of 'inscriptions'. Removing the size limit on OP_RETURN break= s=20 >>> this happenstance obfuscation that has saved us to-date. After this cha= nge,=20 >>> when data is recovered from a full node system, whatever some anonymous= =20 >>> person decided to stuff into an OP_RETURN will be serialized in plainte= xt=20 >>> directly on disk. For the low price of a few sats per byte, an attacker= can=20 >>> now directly poison the storage of every full node runner. >>> >>> If you can't imagine the harm this will do to the ecosystem, let me=20 >>> paint some pictures for you: >>> >>> First, there's the obvious. Everyone running a node will now be=20 >>> guaranteed to "posses and distribute" content that is likely illegal in= =20 >>> their jurisdiction. Not only are you storing this as a full node runner= ,=20 >>> you're serving it to others. Hooray. /s >>> >>> Next, there's less obvious abuses. For example, let's say I want to=20 >>> distribute malware. Well, might as well just store it in an OP_RETURN.= =20 >>> Then, any time I compromise a system with a Bitcoin node I know my malw= are=20 >>> is directly on their system in a mostly predetermined spot already and = I=20 >>> don't even need to retrieve it from elsewhere! And, even better, my mal= ware=20 >>> can use the Bitcoin P2P network itself to distribute itself. Just find = a=20 >>> willing full node, grab the block it's in. Thanks for the boost, node= =20 >>> runners! >>> >>> Worse, in order to actually participate in the network, everyone MUST= =20 >>> download all of this data from others (who must host it for you), proce= ss=20 >>> it, and generally must host it for others to do the same. The network c= an't=20 >>> survive with 100% pruned nodes. I think too many users nowadays don't= =20 >>> understand that running a full node is the ONLY way to actually partici= pate=20 >>> in Bitcoin. >>> >>> It's bad enough that chunked partly-obfuscated things exist on the=20 >>> systems of full node runners today. It'll be even worse if that's=20 >>> unrestricted with the removal of such limits. >>> >>> As I said in my Github comment: This is far more than a small technical= =20 >>> change. This is a fundamental change to the nature of what the Bitcoin= =20 >>> network itself is in its entirety. Ten years ago, developers of the=20 >>> reference implementation knew this, and acted in the best interest of= =20 >>> Bitcoin itself. Today, too many developers don't understand this duty. >>> >>> That may sound like hyperbole, but it really isn't. If this change is= =20 >>> merged into Bitcoin Core, and Bitcoin Core then continues to be the=20 >>> reference implementation... Bitcoin as we know it changes forever in th= e=20 >>> most fundamental way imaginable: The reference implementation explicitl= y=20 >>> turning the Bitcoin network into an arbitrary data storage system, inst= ead=20 >>> of evolving it as a decentralized currency. >>> >>> That's not Bitcoin anymore, and we might as well give up on Bitcoin eve= r=20 >>> being a thing if this is the path chosen. There are very few paths tha= t=20 >>> lead to a worthless Bitcoin, and this is probably in the top 3 worst=20 >>> options. >>> >>> I can't understate this. It's one thing to refuse to act when faced wit= h=20 >>> an attack/exploit/etc. That takes actual courage and conviction to do= =20 >>> what's right for the ecosystem... and I _almost_ can't fault the curren= t=20 >>> batch of devs for not having that courage. However, it's another to op= enly=20 >>> make sweeping changing to the ecosystem in an effort to make such thing= s=20 >>> acceptable. >>> >>> Have the courage to reject this type of thing for the sake of the=20 >>> overall project. >>> >>> JH >>> aka wk057 >>> aka wizkid057 >>> On Saturday, April 26, 2025 at 8:50:59=E2=80=AFAM UTC-4 Pieter Wuille w= rote: >>> >>>> On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr =20 >>>> wrote:=20 >>>> >>>> > That's nonsense. They were and continue to be very effective, even= =20 >>>> with=20 >>>> > only a small amount of adoption. Further, mining centralization and= =20 >>>> >>>> Standardness rules have definitely been effective in the past, if we g= o=20 >>>> far enough back in time. But back then:=20 >>>> >>>> * There were far less financial incentives to bypass them. Standardnes= s=20 >>>> adds inconvenience to people developing infrastructure on top, which c= an=20 >>>> nudge in another direction. But I don't see how million-dollar (or mor= e)=20 >>>> business incentives would be thwarted by the need to communicate with= =20 >>>> miners directly (see below). These incentives will only increase as th= e=20 >>>> subsidy dwindles.=20 >>>> >>>> * There was far more reason for rules of this kind; the network was=20 >>>> small and far less valuable, and there were significant concerns about= =20 >>>> increased node operation cost with a quickly-growing blockchain. With= =20 >>>> blocks consistently full for most of the time for years now, even at t= imes=20 >>>> without so-called "spam", that concern just does not exist; nodes will= be=20 >>>> processing the same amount of transaction data anyway. I think I share= =20 >>>> Luke's feelings around non-financially-relevant transactions on-chain,= but=20 >>>> given sufficient demand for block space anyway, there just is no need = to=20 >>>> discriminate.=20 >>>> >>>> > pools denying miners options has been the biggest barrier to that=20 >>>> > adoption. There is no significant financial impact either, that's=20 >>>> just=20 >>>> > FUD; miners using the fixed and improved spam filters have in fact= =20 >>>> > earned significantly more than miners using Core.=20 >>>> >>>> I am doubtful of this claim, and would like to see evidence of it.=20 >>>> >>>> > It would be a pain, but it is definitely viable. Thankfully, policy= =20 >>>> > works just fine for spam filtration, and can be adapted much quicker= .=20 >>>> >>>> Nobody is required to adopt policy, and I think you're burying your=20 >>>> head in the sand if you believe even in a world with more decentralize= d=20 >>>> hashpower, miners/hashers would voluntarily choose to disregard=20 >>>> transactions that pay a significant fee, if the potential gains from= =20 >>>> accepting them exceed the cost of building infrastructure to bypass=20 >>>> whatever policy exists.=20 >>>> >>>> Bitcoin users do have a means to deny usage of the chain to truly=20 >>>> damaging use: consensus changes. Those are not optional, apply to ever= yone=20 >>>> equally, do not create incentives for bypass, and - and I believe that= is a=20 >>>> good thing - can only be adopted with very wide agreement.=20 >>>> >>>> > > b) centralisation=20 >>>> >=20 >>>> > No, this is more FUD.=20 >>>> >>>> The **entire** reason why Bitcoin uses PoW, as opposed to using a=20 >>>> traditional consensus system with a federation of block-builders, is t= o=20 >>>> avoid censorship. If anyone dislikes the choices current miners make i= n=20 >>>> what transactions they accept, they can - without asking anyone for=20 >>>> permission - join the set of miners, and earn a proportional piece of = the=20 >>>> pie. While it is the case that today mining power is quite concentrate= d in=20 >>>> a number of businesses, the set of such businesses can, and has, chang= ed=20 >>>> over time. This is a very valuable property.=20 >>>> >>>> Part of the puzzle to make that permissionlessness of mining work is= =20 >>>> access to fee-paying transactions from the public. If sufficient econo= mic=20 >>>> demand exist for transactions that the public network denies, miners a= nd=20 >>>> creators of such transaction will develop transaction rails that bypas= s=20 >>>> that network.=20 >>>> >>>> If it comes to a point where that economic demand is so high that=20 >>>> miners need to rely on private transaction rails to realistically comp= ete,=20 >>>> I feel we'd be giving up on one of the most valuable properties the ne= twork=20 >>>> has. I realize this is a slipstreamery-slope argument, but it is alrea= dy=20 >>>> happening, and once the rails are ubiquitous, it will be very hard to = go=20 >>>> back to a public network.=20 >>>> >>>> ---=20 >>>> >>>> Because of all these reasons, Concept ACK on relaxing the OP_RETURN=20 >>>> limits, including removing them entirely. I have been a strong propone= nt of=20 >>>> these limits in the past, and I'm not happy with seeing the demand for= =20 >>>> those transactions. But I also recognize the reality that that demand= =20 >>>> exists, and the alternative of pushing that demand to bypass the publi= c=20 >>>> network is far more damaging.=20 >>>> >>>> I will add that I am not in favor of relaxing many other standardness= =20 >>>> rules in Bitcoin Core, such as transaction sizes and other resource=20 >>>> limitations. These have significant impact on the public's ability to= =20 >>>> verify and relay transactions, and reason about incentive compatibilit= y=20 >>>> while doing so. Significant and sustained economic demand for such=20 >>>> transactions may at some point too mean the policy needs to be revised= to=20 >>>> avoid an even worse outcome, but I'm hopeful that is not the case. How= ever,=20 >>>> these arguments do not apply to OP_RETURN limits, which don't serve an= =20 >>>> objective harm reduction beyond a subjective "that isn't what you shou= ld be=20 >>>> using the chain for".=20 >>>> >>>> --=20 >>>> Pieter=20 >>>> >>>> --=20 >>> You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0= 669cc0a7b8n%40googlegroups.com=20 >>> >>> . >>> >> > > --=20 > *Jason Hughes* > > --=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/= 1e353962-1665-4bc5-8a35-e349fdf4832cn%40googlegroups.com. ------=_Part_75093_1872975406.1746121215961 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW I've written a tool to xor your blocks dir without having to resync. h= ttps://github.com/andrewtoth/blocks-xor/

On Thursday, May 1, 2025 at 5:24= :22=E2=80=AFAM UTC-4 Jason Hughes wrote:
I believe you greatly ove= restimate the skill and competence of the people who would do this type of = thing. You could accomplish what you've laid out. I could accomplish it= . But the people who will actually do this to Bitcoin once there's unre= stricted OP_RETURN likely can not accomplish it today. What you've laid= out is a more technical attack than this variant of attack is capable of..= . and what will actually happen is that once unlimited OP_RETURN is a thing= , people willing to, but not currently able, will take the easy route for s= uch attacks after someone with technical=C2=A0knowledge makes the=C2=A0&quo= t;Connect your wallet, upload your data" button for them.
All of that said, you make excellent=C2=A0points for ridding B= itcoin of arbitrary data completely. :)

On Tue, Apr 29, 2025 at 3:20= =E2=80=AFPM Martin Habov=C5=A1tiak <martin.h...@gmail.com> wrote:
Hi,

I have a little demo for you.

Firstly, I think the kind of illegal content most peopl= e have in mind are images. So let's start with a question: if one takes= an illegal picture and sets every 173th pixel to a red dot will it become = legal?

If you have troub= le imagining it, here's an example for you:=C2=A0https://imgur.com/a/J7RTPL7

If you believe it would, we can end this conversation an= d my point is moot.
However, I think you'll agre= e the image would still be illegal.

Next, I think it's obvious that an attacker seeking to harm= bitcoin users would choose an any image format he likes. So for this examp= le I'm picking BMP.

= If you encode the image above to BMP, which is uncompressed, the red pixels= turn into bytes 253, 7, 2 which happen to encode witness element length 51= 9. The header size is 54 bytes, so stick the byte 54 at the front and you h= ave a valid serialization of a sequence of witness elements.

Do you see what this means?


...


Yes, it's too late to fix this. It's already trivially possible = to make your node store a sequence of bytes that is considered illegal. If = you're worried about it you have to resync the chain right now.

Disclaimer: the numbers above m= ight be a bit off, I did most computation in my head. Still, the point stan= ds even if the pixels have a bit different spacing/color.

Same thing with malware distribution, exc= ept you can easily skip the invalid bytes using jump instructions or other = techniques, so that might be even worse.

<= div dir=3D"auto">Happy syncing!

Martin


D=C5=88a ut 29. 4. 2025, 11:15 Jason Hughe= s (wk057) <wizk...@gmail.com<= /a>> nap=C3=ADsal(a):
I was asked to take my comments to the mailing list, so here we = go.

First, see my comments on Github PR #32359:
-=C2=A0https://github.com/bitcoin/bitco= in/pull/32359#issuecomment-2835467933
-=C2=A0https://github.com/bitcoin/bitcoin/pull/32359= #issuecomment-2835638919
-=C2=A0https://github.com/bitcoin/bitcoin/pull/32359#issuecomment= -2834012756

Next, I'll once again point out relevant history= for those just tuning in:

OP_RETURN was only made standard in a lim= ited size to encourage less harmful data carrying in Bitcoin. Attackers wer= e using harmful methods of data carrying in unspendable UTXOs, and so a way= to inject a small amount of data was TOLERABLE over this harmful UTXO bloa= t that.=C2=A0 That mostly worked, and such practices were quickly minimized= . This remained the case for about a decade without significant issue. Bitc= oin is not file storage, and this was known to developers at that time.=C2= =A0 Sadly, eventually an exploit called 'inscriptions' happened whi= ch blew the cap off of the size limitation of arbitrary data storage... and= to make matters worse, developers refused to patch the exploit or otherwis= e enforce the decade old limit on arbitrary data size. If that wasn't b= ad enough, exploiters get a 75% discount on transaction fees.

With that history in mind, removing limits on=C2=A0OP_RETURN standard= ness size is pointless. Relaxing OP_RETURN size limits without dealing with= the inscriptions exploit means no one will use this for anything besides a= ttacking the network with the worst possible data. There's little to no= incentive to use OP_RETURN for data storage when using the 'inscriptio= ns' exploit costs 4x less in transactions. What's the point of havi= ng a "standard" way to store arbitrary data if the exploit method= is 4x cheaper? And the nonstandard version of the exploit allows 4x the da= ta?

Further, the inscriptions exploit currently requires chunking th= e data between PUSH opcodes, meaning an on-disk analysis doesn't actual= ly directly reveal the underlying data the injector intended.=C2=A0 I can s= till run something like "photorec" on my system and not have to s= ift through thousands of 'inscriptions'. Removing the size limit on= OP_RETURN breaks this happenstance obfuscation that has saved us to-date. = After this change, when data is recovered from a full node system, whatever= some anonymous person decided to stuff into an OP_RETURN will be serialize= d in plaintext directly on disk. For the low price of a few sats per byte, = an attacker can now directly poison the storage of every full node runner.<= div>
If you can't imagine the harm this will do to the ec= osystem, let me paint some pictures for you:

First, there's the = obvious. Everyone running a node will now be guaranteed to "posses and= distribute" content that is likely illegal in their jurisdiction. Not= only are you storing this as a full node runner, you're serving it to = others. Hooray. /s

Next, there's less obvious = abuses. For example, let's say I want to distribute malware. Well, migh= t as well just store it in an OP_RETURN. Then, any time I compromise a syst= em with a Bitcoin node I know my malware is directly on their system in a m= ostly predetermined spot already and I don't even need to retrieve it f= rom elsewhere! And, even better, my malware can use the Bitcoin P2P network= itself to distribute itself. Just find a willing full node, grab the block= it's in. Thanks for the boost, node runners!

Worse, in order to= actually participate in the network, everyone MUST download all of this da= ta from others (who must host it for you), process it, and generally must h= ost it for others to do the same. The network can't survive with 100% p= runed nodes. I think too many users nowadays don't understand that runn= ing a full node is the ONLY way to actually participate in Bitcoin.

It's bad enough that chunked partly-obfuscated things= exist on the systems of full node runners today. It'll be even worse i= f that's unrestricted with the removal of such limits.

As I said in my Github comment:=C2=A0This is far more than a small tech= nical change.=C2=A0This is a fundamental change to the nature of what the B= itcoin network itself is in its entirety. Ten years ago, developers of the = reference implementation knew this, and acted in the best interest of Bitco= in itself. Today, too many developers don't understand this duty.
That may sound like hyperbole, but it really isn't. If this change is= merged into Bitcoin Core, and Bitcoin Core then continues to be the refere= nce implementation... Bitcoin as we know it changes forever in the most fun= damental way imaginable: The reference implementation explicitly turning th= e Bitcoin network into an arbitrary data storage system, instead of evolvin= g it as a decentralized currency.

That's not Bitcoin anymore, an= d we might as well give up on Bitcoin ever being a thing if this is the pat= h chosen.=C2=A0 There are very few paths that lead to a worthless Bitcoin, and this is prob= ably in the top 3 worst options.

I can't understate this. It'= ;s one thing to refuse to act when faced with an attack/exploit/etc.=C2=A0 = That takes actual courage and conviction to do what's right for the eco= system... and I _almost_ can't fault the current batch of devs for not = having that courage.=C2=A0 However, it's another to openly make sweepin= g changing to the ecosystem in an effort to make such things acceptable.
Have the courage to reject this type of thing for the sake of the over= all project.

JH
aka wk057
aka wizkid057
On Satur= day, April 26, 2025 at 8:50:59=E2=80=AFAM UTC-4 Pieter Wuille wrote:
On Saturday, April 26t= h, 2025 at 7:45 AM, Luke Dashjr <lu...@da= shjr.org> wrote:

> That's nonsense. They were and continue to be very effective, = even with
> only a small amount of adoption. Further, mining centralization an= d

Standardness rules have definitely been effective in the past, if we go= far enough back in time. But back then:

* There were far less financial incentives to bypass them. Standardness= adds inconvenience to people developing infrastructure on top, which can n= udge in another direction. But I don't see how million-dollar (or more)= business incentives would be thwarted by the need to communicate with mine= rs directly (see below). These incentives will only increase as the subsidy= dwindles.

* There was far more reason for rules of this kind; the network was sma= ll and far less valuable, and there were significant concerns about increas= ed node operation cost with a quickly-growing blockchain. With blocks consi= stently full for most of the time for years now, even at times without so-c= alled "spam", that concern just does not exist; nodes will be pro= cessing the same amount of transaction data anyway. I think I share Luke= 9;s feelings around non-financially-relevant transactions on-chain, but giv= en sufficient demand for block space anyway, there just is no need to discr= iminate.

> pools denying miners options has been the biggest barrier to that
> adoption. There is no significant financial impact either, that= 9;s just
> FUD; miners using the fixed and improved spam filters have in fact
> earned significantly more than miners using Core.

I am doubtful of this claim, and would like to see evidence of it.

> It would be a pain, but it is definitely viable. Thankfully, polic= y
> works just fine for spam filtration, and can be adapted much quick= er.

Nobody is required to adopt policy, and I think you're burying your= head in the sand if you believe even in a world with more decentralized ha= shpower, miners/hashers would voluntarily choose to disregard transactions = that pay a significant fee, if the potential gains from accepting them exce= ed the cost of building infrastructure to bypass whatever policy exists.

Bitcoin users do have a means to deny usage of the chain to truly damag= ing use: consensus changes. Those are not optional, apply to everyone equal= ly, do not create incentives for bypass, and - and I believe that is a good= thing - can only be adopted with very wide agreement.

> > b) centralisation
>=20
> No, this is more FUD.

The **entire** reason why Bitcoin uses PoW, as opposed to using a tradi= tional consensus system with a federation of block-builders, is to avoid ce= nsorship. If anyone dislikes the choices current miners make in what transa= ctions they accept, they can - without asking anyone for permission - join = the set of miners, and earn a proportional piece of the pie. While it is th= e case that today mining power is quite concentrated in a number of busines= ses, the set of such businesses can, and has, changed over time. This is a = very valuable property.

Part of the puzzle to make that permissionlessness of mining work is ac= cess to fee-paying transactions from the public. If sufficient economic dem= and exist for transactions that the public network denies, miners and creat= ors of such transaction will develop transaction rails that bypass that net= work.

If it comes to a point where that economic demand is so high that miner= s need to rely on private transaction rails to realistically compete, I fee= l we'd be giving up on one of the most valuable properties the network = has. I realize this is a slipstreamery-slope argument, but it is already ha= ppening, and once the rails are ubiquitous, it will be very hard to go back= to a public network.

---

Because of all these reasons, Concept ACK on relaxing the OP_RETURN lim= its, including removing them entirely. I have been a strong proponent of th= ese limits in the past, and I'm not happy with seeing the demand for th= ose transactions. But I also recognize the reality that that demand exists,= and the alternative of pushing that demand to bypass the public network is= far more damaging.

I will add that I am not in favor of relaxing many other standardness r= ules in Bitcoin Core, such as transaction sizes and other resource limitati= ons. These have significant impact on the public's ability to verify an= d relay transactions, and reason about incentive compatibility while doing = so. Significant and sustained economic demand for such transactions may at = some point too mean the policy needs to be revised to avoid an even worse o= utcome, but I'm hopeful that is not the case. However, these arguments = do not apply to OP_RETURN limits, which don't serve an objective harm r= eduction beyond a subjective "that isn't what you should be using = the chain for".

--=20
Pieter

--
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+..= .@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-= c0669cc0a7b8n%40googlegroups.com.


--
Jason Hughes

<= /div>

--
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/1e353962-1665-4bc5-8a35-e349fdf4832cn%40googlegroups.com.
------=_Part_75093_1872975406.1746121215961-- ------=_Part_75092_1221089082.1746121215961--