From: Sjors Provoost <sjors@sprovoost•nl>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Date: Tue, 29 Apr 2025 16:51:09 +0200 [thread overview]
Message-ID: <4DAF69CE-2AA6-4429-9F3C-91030C88A88B@sprovoost.nl> (raw)
In-Reply-To: <f4f6831a-d6b8-4f32-8a4e-c0669cc0a7b8n@googlegroups.com>
Hi Jason,
> OP_RETURN was only made standard in a limited size to encourage less harmful data carrying in Bitcoin.
That's correct.
> 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 you look at the actual pull requests that implement such patches you'll discover the various reasons why they were rejected. This mailinglist thread has also re-iterated the futility of this cat-and-mouse game. It contains 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 fees.
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 to 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 the 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 standardness rules.
In general you're reasoning the wrong around imo. There is no point in restricting transactions that are 4x more expensive than the alternative. And as was explained earlier in this thread by me and others, if we don't drop this 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 blessed by Satoshi were standard. I think it's good that we moved away from that 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 between 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/bitcoin/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 insulting them, you could also just (help) maintain a fork of the project. Working on Knots seems the easiest way to do that. I obviously think you're misguided here, but at least it's better to channel this distrust into something constructive. Given the number of people who share your sentiment, such a project should be perfectly viable.
- Sjors
--
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/4DAF69CE-2AA6-4429-9F3C-91030C88A88B%40sprovoost.nl.
next prev parent reply other threads:[~2025-04-29 15:13 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)
2025-04-29 14:51 ` Sjors Provoost [this message]
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=4DAF69CE-2AA6-4429-9F3C-91030C88A88B@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--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