I (instagibbs) was asked to draft a statement, I feel this is a fair summation of the project's direction. I might be wrong
Bitcoin Core’s next release will, by default, relay and mine transactions whose
OP_RETURN outputs exceed 80 bytes and allow any number of these outputs.
The long-standing cap, originally a gentle signal that block space should be used
sparingly for non-payment proof of publication data, has outlived its utility.
Readers who want the full policy history should consult Bitcoin Optech’s Waiting for
Confirmation mempool series.
Consensus rules decide whether a transaction can ever be included in a block. Standardness rules (aka policy) implemented in Bitcoin Core’s relay code decide whether it is forwarded across the peer-to-peer network before it reaches a miner. Three considerations motivate those extra checks.
- Denial-of-Service defence. Nodes decline transactions that waste CPU, RAM, or bandwidth disproportionate to their fee. E.g., quadratic hashing from legacy scripts.
- Incentive alignment. Giving policy nudges towards wallet authors for fee-efficient yet UTXO-friendly constructions.
- Upgrade safety. Unknown opcodes or version bits remain non-standard until activated by a soft fork, preventing premature use that could hamper future consensus changes.
Standardized OP_RETURN outputs embody that philosophy. Users were
already embedding arbitrary data in spendable outputs, leaving toxic,
unspendable entries in the UTXO set. OP_RETURN gave them a provably
unspendable output that is not added to the UTXO set; the 80-byte ceiling that accompanied it was a
soft deterrent: large enough for a hash or short commitment, too small for
a photograph.
The modern transaction landscape has rendered the legacy cap ineffective and, in several ways, damaging.
A number of private mining accelerators simply do not enforce these limits, and other centralized services use alternative implementations to peer with these miners as well.
Large-data inscriptions are happening regardless and can be done in more or less abusive ways; the cap merely channels them into more opaque forms that cause damage to the network.
When the polite avenue is blocked, determined users turn to impolite ones. Some use bare multisig or craft fake output public keys that do enter the UTXO set, exactly the outcome OP_RETURN was invented to avoid.
Some have proposed an aggressive blacklist against recognised data-embedding tricks. The project declined for both pragmatic and philosophical reasons. It does not stop the most basic forms of data embedding as mentioned before. There is no reliable pattern to detect “bad data”, resulting in a complex game of cat-and-mouse increasing negative externalities, and risks confiscation of user’s funds.
Blocks remain limited to 4 million weight units; dust outputs are still rejected; signature-operation and ancestor/descendant caps still guard mempool growth. The withdrawal of the 80-byte rule yields in at least two tangible benefits:
- Cleaner UTXO set. Data now fits in a single, provably unspendable output rather than being disguised in spendable scripts or spread over multiple transactions.
- Consistent default behaviour. Nodes relay the same transactions miners want to see, making fee estimation and compact-block relay more reliable.
Three possible paths were considered:
- Keep the cap. Rejected as ineffective and arbitrary.
- Raise the cap. Still arbitrary; any figure likely to age poorly.
- Delete the cap. Aligns default policy with actual network practice, minimises incentives for harmful workarounds, and simplifies the relay path.
Option 3 earned broad, though not perhaps unanimous, support. Dissenting parties remain free to modify software, run stricter policy, or propose new resource limits if empirical harm emerges.
The change re-affirms that Bitcoin is governed by transparent, minimal rules rather than editorial preference. By retiring a deterrent that no longer deters, Bitcoin Core keeps the policy surface lean and lets the fee market arbitrate competing demands.
Should a future pattern demonstrably exhaust node resources, targeted protections will be considered as they have been for signature-checking limits, ancestor limits, and dust rules.
@wizkid057 I've carefully read your messages as wells as the other messages from your colleagues at ocean and I have failed to find any clear explanation of the harm we could expect to experience from removing this limit.
It's all well and true that NFT/shitcoin stuff is bad, but there is no reason to expect that this should increase that activity: Anything that can be done with op_return can be done just as well (for the data embedder) with 'fake addresses'. And fake addresses are both far worse for Bitcoin due to bloating the utxo set and are essentially impossible to block. Moreover, parties that want to bypass this limit at scale and particularly for abusive purposes have an easy avenue to do so by directly handing large miners the transactions, which is now a reliable method for getting transactions mined that violate policy.
You've argued that people may put illegal data in the blockchain-- but they already can and wouldn't have any additional ability to do so via this change, they'd do so by stuffing it in signatures where it uses up less block capacity and thus costs less fees. Already nodes 'encrypt' the blocks on disk to prevent this stuff turning up in scanning tools (or photorec) and of course bitcoin core doesn't provide any particular tools to access the data. I don't think more is possible, because one can encode the data to look as indistinguishable as they want-- and parties the spend well over two hundred million dollars on transaction fees for inscriptions over the last couple years are more than capable of hiring whatever technical talent they needed. But most importantly, again, none of that has anything to do with op_return outputs.
I've also found no counter to the benefits of removing the behavior: that at least some of the fake address traffic has indicated it will switch, that any discrepancy between what nodes relay and what miners mine hurts block propagation which advantages large miners at the expense of smaller miners, that direct-to-miner relationships also favor large operations over small, that an incomplete mempool reduces your ability to look at it and tell what price may will get your transactions in the next block, and that a fruitless game of wack-a-mole trying to block transactions creates a dangerously muddled message about the ability of Bitcoin participants to blacklist transactions/addresses such as those on state set blacklists. And of course, simpler code with fewer options and thus combinations of options to test.
So what am I missing here? Please do not respond with an offtopic rant about spam. I don't think anyone in this discussion likes NFTs/shitcoins/etc-- but these things are not relevant unless there is a reason that opreturn traffic would meaningfully increase them and I've yet to see one and think it unlikely you can produce one given the existing alternatives and the fact that bypassing is so easy for anyone willing to go direct to any one of several large miners.