As i have repeatedly asked people to take conceptual discussions to the mailing list, i am circling back to this thread to answer objections. I have also written my point of view and reasons for proposing this change in a blog post which goes into more details:
https://antoinep.com/posts/relay_policy_drama.
Going through the emails in order.
Am I the
only one left on this list who actually cares about Bitcoin's
survival?
Thanks Luke for your measured take. It's refreshing to see we have adults on both sides of this "debate".
With that history in mind, removing limits on OP_RETURN standardness size is pointless.
Yes, it is pointless for people who want to store massive amount of data. It is not for people who want to store a small amount of data in a time-sensitive transaction's output. Because they need their transaction to be relayed on the p2p network, and are therefore pushed to use unspendable outputs instead.
Relaxing OP_RETURN size limits without dealing with the inscriptions
This is orthogonal. The harmful behaviour described in OP is possible today regardless of inscriptions.
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?
You have obviously not properly read or understood OP. There is no need to speculate about what would happen or not. People are using outputs to store data today. The only question now is harm reduction: given that people are storing this data in outputs today, do we want to offer a way to do it that does not force every single full node on the network to store their data forever?
That said i agree that this is not going to change anything for people who try to store large amount of data onchain, they already have a 4x cheaper way of doing so.
For example, let's say I want to distribute malware. Well, might as well just store it in an OP_RETURN.
The point about storing data on everyone's disk was addressed by others: it's already possible and that's why Core XOR's the content of third-party-controlled data it writes to disk. But an interesting fact on this specific point about malware and OP_RETURN outputs is how they have already been used in the past to resiliently update the domain of a malware's C2 servers: https://news.sophos.com/wp-content/uploads/2020/06/glupteba_final-1.pdf .
This is a fundamental change to the nature of what the Bitcoin network itself is in its entirety. [...] Bitcoin as we know it changes forever in the most fundamental way imaginable
Wild emotional claims with no ground whatsoever don't convince anybody and only hurt your credibility.
and we might as well give up on Bitcoin ever being a thing if this is the path chosen
Well if you believe the whole system is as brittle as relying on people playing nice for security, you might as well give up now.
Have the courage to reject this type of thing for the sake of the overall project.
Right. We do that, and you go outside and touch some grass for the benefit of all subscribers to this mailing list.
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. 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.
Doubt.
It was suggested in two different PRs ([0] and [1]) that the conceptual discussion take place in this thread, so I am submitting my comments here.
Thank you for taking conceptual discussion to the mailing list. AJ already addressed your claims, so i won't repeat it here.
This is just a temporary cease-fire while the spammers reload their ammunition. There is obviously about to be another wave
Between this one and your previous email, you certainly do know a lot about the future! How's your trading going?
otherwise what is the point of eliminating OP_RETURN restrictions?
To not force people to bloat the UTxO set to store a trivial amount of data in the output of a time-sensitive transactions. On the specifics, Citrea stores a zk-proof verifying Bitcoin's longest chain composed of a
128-byte Groth16 proof and
16-byte total accumulated work (sauce: https://x.com/ekrembal_/status/1918008476552356202). I don't know and don't care why they do it in this way in particular, i just wish they did so in pruneable OP_RETURN outputs instead of unspendable Taproot outputs as they do today. Or worse, start thinking about bare multisig.
Yes, and then the money printer makes sure that there is always enough easy money sloshing around in the economy so that more pop up where the old ones dropped out. This can and will continue indefinitely if we do nothing.
Money printer financing working people forever certainly isn't something i expected to read on the Bitcoin dev mailing list!
My proposal is not to counter literally every type of spam. Just the ones that have protocols relying on consistent transaction formats. Creating specific filters against just these worst offenders should
This is veering off-topic for this thread. If you want to argue that Core should filter inscriptions could you take it to the appropriate thread? This thread is just about damage control for people storing data in transaction outputs.
I believe you greatly overestimate the skill and competence of the people who would do this type of thing. You could accomplish what you've laid out. I could accomplish it.
Your hubris gives me second-hand embarrassment. I hope the C2 domain update i shared above gives you a clue that there does in fact exist other smart people in the world. Threat actors would laugh pretty hard at your arrogant emails and emotional breakdowns, but they probably don't care about your filters in the slightest anyways.
After reading the whole thread i have yet to read a single sound objection to lifting the OP_RETURN restrictions.
On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot <
daro...@protonmail.com> wrote:
Hi,
Standardness rules exist for 3 mains reasons: mitigate DoS vectors, provide upgrade hooks, or as a nudge to deter some usages.
Bitcoin Core will by default only relay and mine transactions with at most a single OP_RETURN output, with a scriptPubKey no larger than 83 bytes. This standardness rule falls into the third category: it aims to mildly deter data storage while still allowing a less harmful alternative than using non-provably-unspendable outputs.
Developers are now designing constructions that work around these limitations. An example is Clementine, the recently-announced Citrea bridge, which uses unspendable Taproot outputs to store data in its "WatchtowerChallenge" transaction due to the standardness restrictions on the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineffective to deter storing data onchain.
Since the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage, i propose to drop them. I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encouraging harmful behaviour, and to then proceed to lift the restriction on the number of OP_RETURN outputs per transactions.
Antoine Poinsot