path: root/c8/34f5235b78411031a8c852a22aea8bac39ca6f

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 <bitcoindev+bncBD2MXBGMTMEBBDV6YPAAMGQEG2T6DMQ@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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)" <wizkid057@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n@googlegroups.com>
In-Reply-To: <QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs=@wuille.net>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org>
 <CEB83B34-6C5B-469E-9914-20940F27EEC0@sprovoost.nl>
 <d18b4149-5523-44bd-8332-2b7962f4b674@dashjr.org>
 <QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs=@wuille.net>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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 <lu...@dashjr.org>=
=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.<br /><b=
r />First, see my comments on Github PR #32359:<br />-=C2=A0https://github.=
com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933<br />-=C2=A0https://=
github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638919<br />-=C2=A0h=
ttps://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756<br /><=
br />Next, I'll once again point out relevant history for those just tuning=
 in:<br /><br />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.<div><br /></div><div>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?<br /><br />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=
.<div><br /></div><div>If you can't imagine the harm this will do to the ec=
osystem, let me paint some pictures for you:<br /><br />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</div><div><br /></div><div>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!<br /><br />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.</div><div><br /></div><div>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.</div><div><br /></div>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.<br /><br />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.<br /><br=
 />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.<br /><br />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.<br /><br />Have th=
e courage to reject this type of thing for the sake of the overall project.=
</div><div><br /></div><div>JH<br />aka wk057<br />aka wizkid057</div><div =
class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Saturday, A=
pril 26, 2025 at 8:50:59=E2=80=AFAM UTC-4 Pieter Wuille wrote:<br/></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: =
1px solid rgb(204, 204, 204); padding-left: 1ex;">On Saturday, April 26th, =
2025 at 7:45 AM, Luke Dashjr &lt;<a href data-email-masked rel=3D"nofollow"=
>lu...@dashjr.org</a>&gt; wrote:
<br>
<br>&gt; That&#39;s nonsense. They were and continue to be very effective, =
even with
<br>&gt; only a small amount of adoption. Further, mining centralization an=
d
<br>
<br>Standardness rules have definitely been effective in the past, if we go=
 far enough back in time. But back then:
<br>
<br>* 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&#39;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.
<br>
<br>* 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 &quot;spam&quot;, that concern just does not exist; nodes will be pro=
cessing the same amount of transaction data anyway. I think I share Luke&#3=
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.
<br>
<br>&gt; pools denying miners options has been the biggest barrier to that
<br>&gt; adoption. There is no significant financial impact either, that&#3=
9;s just
<br>&gt; FUD; miners using the fixed and improved spam filters have in fact
<br>&gt; earned significantly more than miners using Core.
<br>
<br>I am doubtful of this claim, and would like to see evidence of it.
<br>
<br>&gt; It would be a pain, but it is definitely viable. Thankfully, polic=
y
<br>&gt; works just fine for spam filtration, and can be adapted much quick=
er.
<br>
<br>Nobody is required to adopt policy, and I think you&#39;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.
<br>
<br>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.
<br>
<br>&gt; &gt; b) centralisation
<br>&gt;=20
<br>&gt; No, this is more FUD.
<br>
<br>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.
<br>
<br>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.
<br>
<br>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&#39;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.
<br>
<br>---
<br>
<br>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&#39;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.
<br>
<br>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&#39;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&#39;m hopeful that is not the case. However, these arguments =
do not apply to OP_RETURN limits, which don&#39;t serve an objective harm r=
eduction beyond a subjective &quot;that isn&#39;t what you should be using =
the chain for&quot;.
<br>
<br>--=20
<br>Pieter
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com</a>.<br />

------=_Part_21291_1349039569.1745857214508--

------=_Part_21290_1522658487.1745857214508--