Delivery-date: Tue, 29 Apr 2025 08:13:42 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.153 as permitted sender) client-ip=202.12.124.153;
Feedback-ID: ie5e042df:Fastmail
From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Date: Tue, 29 Apr 2025 16:51:09 +0200
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>
 <f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
In-Reply-To: <f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n@googlegroups.com>
Message-Id: <4DAF69CE-2AA6-4429-9F3C-91030C88A88B@sprovoost.nl>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

Hi Jason,

> OP_RETURN was only made standard in a limited size to encourage less harm=
ful data carrying in Bitcoin.

That's correct.

> and this was known to developers at that time.  Sadly, eventually an expl=
oit called 'inscriptions' happened which blew the cap off of the size limit=
ation of arbitrary data storage... and to make matters worse, developers re=
fused to patch the exploit or otherwise enforce the decade old limit on arb=
itrary data size.

If you look at the actual pull requests that implement such patches you'll =
discover the various reasons why they were rejected.  This mailinglist thre=
ad has also re-iterated the futility of this cat-and-mouse game. It contain=
s the relevant links, so I'm not going to repeat them here.

> If that wasn't bad enough, exploiters get a 75% discount on transaction f=
ees.

At the time SegWit was proposed it was clear that the worst case block size=
 would increase to 4 MB. It took a few years for people to figure out how t=
o take advantage of that. Somewhere between 2015 and early 2017 would have =
been good time to object to the SegWit discount, but removing it now would =
be a hard fork. Fwiw I think the discount was a good idea.

>  What's the point of having a "standard" way to store arbitrary data if t=
he exploit method is 4x cheaper? And the nonstandard version of the exploit=
 allows 4x the data?

What you call "nonstandard" is actually standard. Inscriptions follow stand=
ardness rules.

In general you're reasoning the wrong around imo. There is no point in rest=
ricting transactions that are 4x more expensive than the alternative. And a=
s was explained earlier in this thread by me and others, if we don't drop t=
his limit then the UTXO set will get bloated. Just as you point out was the=
 historical issue.

Bitcoin Core used to have a whitelist model where only a few transaction bl=
essed by Satoshi were standard. I think it's good that we moved away from t=
hat to where you typically don't have to lobby for your transaction type to=
 be included. But others disagree, e.g. Luke Dashr in this thread proposed =
going back to that model.

> Further, the inscriptions exploit currently requires chunking the data be=
tween PUSH opcodes

The issue of consecutive byte sequences stored on disk is intestering. But =
imo it has been fully addressed on the Github PR now: https://github.com/bi=
tcoin/bitcoin/pull/32359#issuecomment-2838068278

In summary:

1. The mempool is encrypted at rest
2. The blockchain is encrypted at rest for (relatively) new users, but not =
for everyone. However, it is already trivial to inject arbitrary data into =
the blockchain.

This change does not make the problem worse.

> That may sound like hyperbole, but it really isn't.

It's irrelevant because this PR does not change the threats you are worried=
 about.

>  Today, too many developers don't understand this duty.

If you don't have confidence in the Bitcoin Core developers, instead of ins=
ulting them, you could also just (help) maintain a fork of the project. Wor=
king on Knots seems the easiest way to do that. I obviously think you're mi=
sguided here, but at least it's better to channel this distrust into someth=
ing constructive. Given the number of people who share your sentiment, such=
 a project should be perfectly viable.

- Sjors

--=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/=
4DAF69CE-2AA6-4429-9F3C-91030C88A88B%40sprovoost.nl.