From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 29 Apr 2025 07:15:55 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1u9lkX-0002cO-6h for bitcoindev@gnusha.org; Tue, 29 Apr 2025 07:15:54 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-2d4e42a2b2bsf4362683fac.0 for ; Tue, 29 Apr 2025 07:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1745936146; x=1746540946; 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=HGa0Ea0YRCvOqbmuQ6pt0JJKvcC77F/rnc6GDfYSkP4=; b=iSPryrAHQcx/VPOnzl67TgJuZd3c8MKKDRejtSWDpCIPmSM6W1sMa9RjNPw5fVB+GM hsWTLNW/j+x6tPpfGmoZLUPg5QNFLGxCRm1SUQ6C/0rRXoPBwCyMgF6+oUAYqjrnxMoi LwuGOOYK7tUp6UGraqsovHjuyI0apNiVKT7urEzJf3FkZ+523IFxDyiNsDPRJzgSfMnk 07lX6p8zYtuaTtqHxWldoZQaOjx5gKyaEgN/j5uO1JolMCMm503HR3edB9/xRDB/IGds Hg5Uq8ARL2BgC4mHUHZRQ+cTdchhTtzbC/uPy/ICdhgW33gnq0tkNEQT0obBwMu8c8Yo 2rDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745936146; x=1746540946; 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=HGa0Ea0YRCvOqbmuQ6pt0JJKvcC77F/rnc6GDfYSkP4=; b=TU1kggW9g/repKHSBVOi2IqWdgbdK/TJSr/H4/Y3GzkNsSP6CHKqX9M383OX9KT70a I3KuvWyNzTV9RDVZ0dewclMgZ2ZQVI+3pWUa6eoinfS+Ql5XmEU1pd7skKIaWnPlmlwZ /LzHE3n9m+hZlnXgafOgXKBnRlOdqAPEIM+lqOOjJMyn3MKAgsWumG8jnwase9rNhF86 uXHqKHyq9UozF9dJ+1DU8WynwshFrWIjSvCg9lI5w9bNCkxRPGepCASaD1wOKWEyghzU kPjiCFzpkLSqBvgwIM6yo/5XOIhuLikMZ49xsqBh4IocTjcN38I3HaQmd1Tr0m9+CeJi R3yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745936146; x=1746540946; 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=HGa0Ea0YRCvOqbmuQ6pt0JJKvcC77F/rnc6GDfYSkP4=; b=ETXtAZlDAsMeqad326rAWf43KYkxs1B0tehWKId6Un3GSV3bQyxUPdgwcr6NSaRwTU QKFV06pda7J0/oqPMh1AaWlOJUn8H64OYEAe/ZUpt5uiRy1scSp9ETs6TLDBMUfPP7FH sDeYahdBCQrLW8CzVQgPClp1D78duWBqyiNkQjm2mPbPrufJm5MCe3bl1/ph5A0y7csU eN15Ptda+DPAjcFxLyEAkM4Goo0iinRxwD4qGsKNMpbar35NXpD3srRycaH1TAwU9hSw ttYnrIiBtrJECkn3IxSma479nQOiXbeU3Wkf7mwvZLWrmGRIZteWhhdFgcmWEc67GYye h1lg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXGvLZ/ApqSNNVwacZ8sXicsH28pGeg3MF2Dx6U+FtatyRigyfHabotVNMbeG+HuAcW1R53NyUH3LSD@gnusha.org X-Gm-Message-State: AOJu0Yz7+y+BcR1jOiUcFCfZYsGM/F8T8WwczH25A5tBF64tmVONWUuz NINuiRiF7Xxr1RBcpf5kxC6fi4flqz8ro/H90EuU+UESixLkBCVY X-Google-Smtp-Source: AGHT+IEgp9uVb3F1WW0uf8s7jPJNtPywslgnZ5rxlsSPjBvrjZzgi6ZdvEkIv89i1BBCek3fkhBUIw== X-Received: by 2002:a05:6870:71d2:b0:2d6:241:aed5 with SMTP id 586e51a60fabf-2d9be88c23amr7944353fac.26.1745936145646; Tue, 29 Apr 2025 07:15:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBGU4QM2T0BXtIs+f+vdmpGOUcgrF4CZS+POe7rXwtMwxQ== Received: by 2002:a25:b128:0:b0:e72:89f3:c184 with SMTP id 3f1490d57ef6-e730820ac9als451508276.0.-pod-prod-03-us; Tue, 29 Apr 2025 07:15:42 -0700 (PDT) X-Received: by 2002:a05:690c:46c8:b0:6fd:a226:fb2b with SMTP id 00721157ae682-7089b16566dmr43220247b3.3.1745936141885; Tue, 29 Apr 2025 07:15:41 -0700 (PDT) Received: by 2002:a0d:c202:0:b0:706:b535:945d with SMTP id 00721157ae682-70854d8a0bbms7b3; Mon, 28 Apr 2025 09:20:16 -0700 (PDT) X-Received: by 2002:a05:690c:4912:b0:703:b3f8:9e7d with SMTP id 00721157ae682-7085412a9d6mr178430267b3.19.1745857214846; Mon, 28 Apr 2025 09:20:14 -0700 (PDT) Date: Mon, 28 Apr 2025 09:20:14 -0700 (PDT) From: "Jason Hughes (wk057)" To: Bitcoin Development Mailing List Message-Id: 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_21290_1522658487.1745857214508" X-Original-Sender: wizkid057@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_21290_1522658487.1745857214508 Content-Type: multipart/alternative; boundary="----=_Part_21291_1349039569.1745857214508" ------=_Part_21291_1349039569.1745857214508 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 amount= =20 of data was TOLERABLE over this harmful UTXO bloat that. That mostly=20 worked, and such practices were quickly minimized. This remained the case= =20 for about a decade without significant issue. Bitcoin is not file storage,= =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 size= =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 size= =20 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 no=20 incentive to use OP_RETURN for data storage when using the 'inscriptions'= =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 cheaper?= =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 directly= =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 breaks=20 this happenstance obfuscation that has saved us to-date. After this change,= =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 plaintext= =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 paint= =20 some pictures for you: First, there's the obvious. Everyone running a node will now be guaranteed= =20 to "posses and distribute" content that is likely illegal in their=20 jurisdiction. Not only are you storing this as a full node runner, you're= =20 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 malware= =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 malware= =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), process= =20 it, and generally must host it for others to do the same. The network can'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 participate= =20 in Bitcoin. It's bad enough that chunked partly-obfuscated things exist on the systems= =20 of full node runners today. It'll be even worse if that's unrestricted with= =20 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 the=20 most fundamental way imaginable: The reference implementation explicitly=20 turning the Bitcoin network into an arbitrary data storage system, instead= =20 of evolving it as a decentralized currency. That's not Bitcoin anymore, and we might as well give up on Bitcoin ever=20 being a thing if this is the path chosen. There are very few paths that=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 with an= =20 attack/exploit/etc. That takes actual courage and conviction to do what's= =20 right for the ecosystem... and I _almost_ can't fault the current batch of= =20 devs for not having that courage. However, it's another to openly make=20 sweeping changing to the ecosystem in an effort to make such things=20 acceptable. Have the courage to reject this type of thing for the sake of the overall= =20 project. JH aka wk057 aka wizkid057 On Saturday, April 26, 2025 at 8:50:59=E2=80=AFAM UTC-4 Pieter Wuille wrote= : > On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr = =20 > wrote: > > > That's nonsense. They were and continue to be very effective, even with > > only a small amount of adoption. Further, mining centralization and > > Standardness rules have definitely been effective in the past, if we go= =20 > far enough back in time. But back then: > > * There were far less financial incentives to bypass them. Standardness= =20 > adds inconvenience to people developing infrastructure on top, which can= =20 > nudge in another direction. But I don't see how million-dollar (or more)= =20 > business incentives would be thwarted by the need to communicate with=20 > miners directly (see below). These incentives will only increase as the= =20 > subsidy dwindles. > > * There was far more reason for rules of this kind; the network was small= =20 > and far less valuable, and there were significant concerns about increase= d=20 > node operation cost with a quickly-growing blockchain. With blocks=20 > consistently full for most of the time for years now, even at times witho= ut=20 > 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, bu= t=20 > given sufficient demand for block space anyway, there just is no need to= =20 > discriminate. > > > pools denying miners options has been the biggest barrier to that > > adoption. There is no significant financial impact either, that'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, policy > > works just fine for spam filtration, and can be adapted much quicker. > > Nobody is required to adopt policy, and I think you're burying your head= =20 > in the sand if you believe even in a world with more decentralized=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. > > Bitcoin users do have a means to deny usage of the chain to truly damagin= g=20 > use: consensus changes. Those are not optional, apply to everyone equally= ,=20 > do not create incentives for bypass, and - and I believe that is a good= =20 > 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=20 > traditional consensus system with a federation of block-builders, is to= =20 > avoid censorship. If anyone dislikes the choices current miners make in= =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 concentrated i= n=20 > a number of businesses, the set of such businesses can, and has, changed= =20 > over time. This is a very valuable property. > > Part of the puzzle to make that permissionlessness of mining work is=20 > access to fee-paying transactions from the public. If sufficient economic= =20 > demand exist for transactions that the public network denies, miners and= =20 > creators of such transaction will develop transaction rails that bypass= =20 > that network. > > If it comes to a point where that economic demand is so high that miners= =20 > need to rely on private transaction rails to realistically compete, I fee= l=20 > we'd be giving up on one of the most valuable properties the network has.= I=20 > realize this is a slipstreamery-slope argument, but it is already=20 > happening, and once the rails are ubiquitous, it will be very hard to go= =20 > back to a public network. > > --- > > Because of all these reasons, Concept ACK on relaxing the OP_RETURN=20 > limits, including removing them entirely. I have been a strong proponent = 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 public= =20 > network is far more damaging. > > 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 compatibility= =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. Howeve= r,=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 should = be=20 > using the chain for". > > --=20 > Pieter > > --=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/= f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com. ------=_Part_21291_1349039569.1745857214508 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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/bitcoin/pull/32359#issuecomment-2835467933
-=C2=A0https://= github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638919
-=C2=A0h= ttps://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756
<= br />Next, I'll once again point out relevant history for those just tuning= in:

OP_RETURN was only made standard in a limited size to encou= rage less harmful data carrying in Bitcoin. Attackers were using harmful me= thods of data carrying in unspendable UTXOs, and so a way to inject a small= amount of data was TOLERABLE over this harmful UTXO bloat that.=C2=A0 That= mostly worked, and such practices were quickly minimized. This remained th= e case for about a decade without significant issue. Bitcoin is not file st= orage, and this was known to developers at that time.=C2=A0 Sadly, eventual= ly an exploit called 'inscriptions' happened which blew the cap off of the = size limitation of arbitrary data storage... and to make matters worse, dev= elopers refused to patch the exploit or otherwise enforce the decade old li= mit on arbitrary data size. If that wasn't bad enough, exploiters get a 75%= discount on transaction fees.

With that history in mi= nd, removing limits on=C2=A0OP_RETURN standardness size is pointless. Relax= ing OP_RETURN size limits without dealing with the inscriptions exploit mea= ns no one will use this for anything besides attacking the network with the= worst possible data. There's little to no incentive to use OP_RETURN for d= ata storage when using the 'inscriptions' exploit costs 4x less in transact= ions. What's the point of having a "standard" way to store arbitrary data i= f the exploit method is 4x cheaper? And the nonstandard version of the expl= oit allows 4x the data?

Further, the inscriptions exploit curren= tly requires chunking the data between PUSH opcodes, meaning an on-disk ana= lysis doesn't actually directly reveal the underlying data the injector int= ended.=C2=A0 I can still run something like "photorec" on my system and not= have to sift 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, whatev= er some anonymous person decided to stuff into an OP_RETURN will be seriali= zed 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= .

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 dist= ribute" 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 exam= ple, let's say I want to distribute malware. Well, might as well just store= it in an OP_RETURN. Then, any time I compromise a system with a Bitcoin no= de I know my malware is directly on their system in a mostly predetermined = spot already and I don't even need to retrieve it from elsewhere! And, even= better, my malware can use the Bitcoin P2P network itself to distribute it= self. 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 data from others (who must= host it for you), process it, and generally must host it for others to do = the same. The network can't survive with 100% pruned nodes. I think too man= y users nowadays don't understand that running a full node is the ONLY way = to actually participate in Bitcoin.

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

As I said in my Github comment:=C2= =A0This is far more than a small technical change.=C2=A0This is a fundament= al change to the nature of what the Bitcoin network itself is in its entire= ty. Ten years ago, developers of the reference implementation knew this, an= d acted in the best interest of Bitcoin itself. Today, too many developers = don't understand this duty.

That may sound like hyperbole, but i= t really isn't. If this change is merged into Bitcoin Core, and Bitcoin Cor= e then continues to be the reference implementation... Bitcoin as we know i= t changes forever in the most fundamental way imaginable: The reference imp= lementation explicitly turning the Bitcoin network into an arbitrary data s= torage system, instead of evolving it as a decentralized currency.
That's not Bitcoin anymore, and we might as well give up on Bitcoin ever= being a thing if this is the path 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 o= ne 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 ecosystem..= . 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 sweeping changing to th= e ecosystem in an effort to make such things acceptable.

Have th= e courage to reject this type of thing for the sake of the overall project.=

JH
aka wk057
aka wizkid057
On Saturday, A= pril 26, 2025 at 8:50:59=E2=80=AFAM UTC-4 Pieter Wuille wrote:
On Saturday, April 26th, = 2025 at 7:45 AM, Luke Dashjr <lu...@dashjr.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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com.
------=_Part_21291_1349039569.1745857214508-- ------=_Part_21290_1522658487.1745857214508--