-
@ Andy
2025-05-08 09:29:23A detailed breakdown of the recent debate around Bitcoin Core’s proposed policy change to OP_RETURN — and why it’s less dramatic than some fear.
TL;DR
Removing the 80-byte OP_RETURN limit is a mempool policy cleanup, not a consensus rule change. It reduces UTXO bloat, improves relay consistency, and doesn’t affect Bitcoin’s monetary properties or block size limits.
What Is OP_RETURN?
OP_RETURNis a Bitcoin script opcode introduced in 2014 (Bitcoin Core 0.9.0) to allow small amounts of arbitrary data to be embedded in transactions. Crucially, it creates provably unspendable outputs, preventing UTXO set pollution.A default policy limit of 80 bytes was added to discourage non-payment data usage while still allowing basic use cases (e.g., hashes, commitments).
Why Was OP_RETURN Added? (Bitcoin Core 0.9, March 2014)
When OP_RETURN was introduced, it wasn’t to promote on-chain data — it was a harm-reduction tool:
“This change is not an endorsement of storing data in the blockchain... [It] creates a provably-prunable output, to avoid data storage schemes... storing arbitrary data... bloating Bitcoin’s UTXO database.” — Bitcoin Core 0.9 Release Notes
Before that, users embedded data in fake outputs, bloating the UTXO set and degrading node performance.
OP_RETURN made those outputs prunable and cleaner, though it imposed an 80-byte policy cap — not a consensus rule.
What’s Actually Changing?
Bitcoin Core PR #32359 proposes:
- Removing the 80-byte policy limit on OP_RETURN data
- Removing the
-datacarrierand-datacarriersizeconfiguration options - Default behavior will now relay (and mine) larger OP_RETURNs
⚠️ This is not a consensus change. Blocks stay limited to \~4MB. No rules about block validity are altered.
Why It’s Not a Big Deal
- ✅ Consensus stays the same: No risk of chain splits
- ✅ Block size stays capped (\~4MB)
- ✅ You can still run Bitcoin Knots if you prefer stricter policies
- ✅ Transaction size limit (\~100KB) remains for DoS protection
Bottom line: This is a configuration tweak to improve consistency between nodes and miners.
Common Uses of OP_RETURN
- Timestamping
- Cross-chain anchoring (e.g., merge-mined sidechains)
- Asset issuance (e.g., Omni/Tether)
- Notarization and commitments
- Metadata for protocols like Citrea
📝 In contrast, Ordinal inscriptions use witness data; Stamps use fake outputs — not OP_RETURN.
Arguments For Removing the Limit
- The limit is ineffective — easily bypassed via witness/multisig/fake outputs
- Cleaner data paths — prevents UTXO bloat from “Stamp”-style tricks
- Reflects mining reality — miners already include these transactions
- Improves relay/mempool consistency
- Avoids centralization risks — removes miner advantages from custom policies
- Enables metaprotocols — safely embed structured metadata without abusing Bitcoin’s core design
Arguments Against Removing the Limit
- Risk of encouraging non-monetary use
- Fears of "spam" or NFT-like inscriptions
- Concerns over governance process
- Perceived erosion of Bitcoin’s monetary purity
🧠 Note: The 80-byte cap was policy, not consensus. Removing it doesn’t allow anything that wasn’t already valid on-chain.
Policy vs. Consensus
- Policy rules affect relay and mempool behavior
- Consensus rules affect what blocks are considered valid
Large OP_RETURNs are already valid. The inconsistency is that many nodes don’t relay them, while miners do include them. This change aligns relay with mining, improving propagation and fee estimation.
Bitcoin Knots: A Protest Client
Bitcoin Knots (maintained by Luke Dashjr) retains the old 80-byte policy. After the PR surfaced, some users switched to Knots as a protest.
According to Matthew R. Kratter, Bitcoin Knots briefly surpassed Core 29.0 in node count during early 2025 — but this spike appears to have been driven more by timing mismatches between release cycles and a coordinated protest campaign, rather than a durable shift in user adoption. In fact, most Bitcoin nodes today still run older versions of Core. As of May 2025, Core 28.1.0 alone accounts for over 21% of nodes, while Core 29.0.0 sits below 6%, and Knots 20250305 trails at just over 6% — suggesting that the majority of the network remains on pre-29 Core versions rather than switching to Knots en masse.
Broader Implications
- 🛠️ Highlights tensions between devs, miners, and users over governance
- 🧭 Shows how non-consensus rules can impact perceived neutrality
- 🧪 Sparks renewed focus on tooling (e.g., ASMap, better banlists, relay filtering)
- 🔐 Reaffirms user sovereignty through client diversity
Final Thoughts
Removing the OP_RETURN limit aligns Bitcoin Core’s policy with reality — what’s already getting mined — while cleaning up harmful workarounds.
It won’t break Bitcoin.
But it does surface deeper tensions about Bitcoin’s purpose, evolution, and who ultimately decides what gets built and accepted.
References
- PR: Remove arbitrary limits on OP_RETURN #32359
- PR: Deprecate datacarrier options #32406
- Mailing list: Relax OP_RETURN standardness restrictions
- Gist with full community discussion
- Bitcoin Knots
- Kratter video: Bitcoin Core Removes the Mask
🙏 Acknowledgements
Thanks to @hodlinator, ShiShi21m, and many others in the community for their thoughtful insights, corrections, and spirited discussion.
Based on the original GitHub Gist: Bitcoin OP_RETURN Controversy: Complete Summary