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.
I think this sentence is inaccurate.
Technically speaking, "inscriptions" refer specifically to the
OP_FALSE OP_IF "ord" … OP_ENDIFenvelope construction embedded in a tapscript, and are not a generic term for "big data put anywhere in a transaction". So they can only be made in one way, which is not particularly abusive. Stamps, for example, which embed data in fake outputs, are not inscriptions.