From: "Jason Hughes (wk057)" <wizkid057@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Date: Mon, 28 Apr 2025 09:20:14 -0700 (PDT) [thread overview]
Message-ID: <f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n@googlegroups.com> (raw)
In-Reply-To: <QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs=@wuille.net>
[-- Attachment #1.1: Type: text/plain, Size: 11151 bytes --]
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
harmful data carrying in Bitcoin. Attackers were 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 bloat that. That mostly
worked, and such practices were quickly minimized. This remained the case
for about a decade without significant issue. Bitcoin is not file storage,
and this was known to developers at that time. Sadly, eventually an
exploit called 'inscriptions' happened which blew the cap off of the size
limitation of arbitrary data storage... and to make matters worse,
developers refused to patch the exploit or otherwise enforce the decade old
limit on arbitrary data size. If that wasn't bad enough, exploiters get a
75% discount on transaction fees.
With that history in mind, removing limits on OP_RETURN standardness size
is pointless. Relaxing OP_RETURN size limits without dealing with the
inscriptions exploit means 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 data storage when using the 'inscriptions'
exploit costs 4x less in transactions. What's the point of having a
"standard" way to store arbitrary data if the exploit method is 4x cheaper?
And the nonstandard version of the exploit allows 4x the data?
Further, the inscriptions exploit currently requires chunking the data
between PUSH opcodes, meaning an on-disk analysis doesn't actually directly
reveal the underlying data the injector intended. 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, whatever some anonymous
person decided to stuff into an OP_RETURN will be serialized 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 ecosystem, 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, might as well just store it in an OP_RETURN.
Then, any time I compromise a system with a Bitcoin node 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 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 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 many users nowadays don't
understand that running 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 if that's unrestricted with
the removal of such limits.
As I said in my Github comment: This is far more than a small technical
change. This is a fundamental change to the nature of what the Bitcoin
network itself is in its entirety. Ten years ago, developers of the
reference implementation knew this, and acted in the best interest of
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
merged into Bitcoin Core, and Bitcoin Core then continues to be the
reference implementation... Bitcoin as we know it changes forever in the
most fundamental way imaginable: The reference implementation explicitly
turning the Bitcoin network into an arbitrary data storage 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. There are very few paths that
lead to a worthless Bitcoin, and this is probably 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. 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. However, it's another to openly make
sweeping 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 overall
project.
JH
aka wk057
aka wizkid057
On Saturday, April 26, 2025 at 8:50:59 AM 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 and
>
> 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
> nudge in another direction. But I don't see how million-dollar (or more)
> business incentives would be thwarted by the need to communicate with
> miners 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 small
> and far less valuable, and there were significant concerns about increased
> node operation cost with a quickly-growing blockchain. With blocks
> consistently full for most of the time for years now, even at times without
> so-called "spam", that concern just does not exist; nodes will be
> processing the same amount of transaction data anyway. I think I share
> Luke's feelings around non-financially-relevant transactions on-chain, but
> given sufficient demand for block space anyway, there just is no need to
> 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
> in the sand if you believe even in a world with more decentralized
> hashpower, miners/hashers would voluntarily choose to disregard
> transactions that pay a significant fee, if the potential gains from
> accepting them exceed the cost of building infrastructure to bypass
> whatever policy exists.
>
> Bitcoin users do have a means to deny usage of the chain to truly damaging
> use: consensus changes. Those are not optional, apply to everyone equally,
> 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
> >
> > No, this is more FUD.
>
> The **entire** reason why Bitcoin uses PoW, as opposed to using a
> traditional consensus system with a federation of block-builders, is to
> avoid censorship. If anyone dislikes the choices current miners make in
> what transactions 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 the case that today mining power is quite concentrated in
> a number of businesses, 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
> access to fee-paying transactions from the public. If sufficient economic
> demand exist for transactions that the public network denies, miners and
> creators of such transaction will develop transaction rails that bypass
> that network.
>
> If it comes to a point where that economic demand is so high that miners
> need to rely on private transaction rails to realistically compete, I feel
> 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
> happening, 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
> limits, including removing them entirely. I have been a strong proponent of
> these limits in the past, and I'm not happy with seeing the demand for
> those 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
> rules in Bitcoin Core, such as transaction sizes and other resource
> limitations. These have significant impact on the public's ability to
> verify and 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 outcome, 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 reduction beyond a subjective "that isn't what you should be
> using the chain for".
>
> --
> Pieter
>
>
--
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 email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 11781 bytes --]
next prev parent reply other threads:[~2025-04-29 14:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:52 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 21:34 ` Antoine Riard
2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2025-04-26 10:53 ` Sjors Provoost
2025-04-26 11:35 ` Luke Dashjr
2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille
2025-04-28 16:20 ` Jason Hughes (wk057) [this message]
2025-04-29 14:51 ` Sjors Provoost
2025-04-29 19:20 ` Martin Habovštiak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n@googlegroups.com \
--to=wizkid057@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox