andy108369/op_return_controversy_summary.md

## op_return_controversy_summary.md

      
    Raw
  

              op_return_controversy_summary.md
            
          
    Bitcoin OP_RETURN Controversy: Complete Summary


⚡ TL;DR: Bitcoin Core is removing the 80-byte OP_RETURN relay limit — a policy, not consensus, change.
It aligns with how miners already behave, but reduces node configurability.
Relay policy is policy — and what nodes don’t forward rarely gets mined.
Spam resistance should come from fees and filters, not hardcoded caps.
Bitcoin runs on rules, not rulers. Let the market and nodes decide — not just Core.

Intro (for non-techies)

Bitcoin Core plans to remove a size limit on data stored in special transactions called OP_RETURN, but this is a policy change, not a consensus change.
What is OP_RETURN?


OP_RETURN is 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).


Historical Context: Why OP_RETURN Was Introduced (Bitcoin Core 0.9, March 2014)

When OP_RETURN was introduced in Bitcoin Core 0.9, it was not meant to encourage data storage on-chain. Instead, it was a harm-reduction feature:

“This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes — some of which were already deployed — that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating Bitcoin’s UTXO database.”


— Bitcoin Core 0.9 Release Notes (March 2014)

Before OP_RETURN, users were already embedding data in fake outputs, which polluted the UTXO set (the set of unspent coins all full nodes track in memory).
OP_RETURN allowed data to be embedded in a provably unspendable output, which:


Makes the output prunable, improving node performance


Avoids permanently bloating the UTXO set


Encouraged safer practices while still discouraging large-scale non-financial data storage


The 80-byte cap was a policy deterrent, not a consensus limit — large OP_RETURNs were discouraged, not invalid.
🔹 What does that mean?

The fundamental rules of Bitcoin — like the 4 MB block size limit — are not changing.
This change only affects how the Bitcoin Core software relays certain types of data transactions, not what it considers valid in a block.

🔹 What is changing?

Bitcoin Core will stop enforcing an 80-byte size limit on OP_RETURN data, allowing larger metadata transactions to be shared between nodes.
Miners already include such transactions using custom policy settings.


🧘‍♂️ Why Bitcoiners Don’t Need to Panic


✅ No risk of a chain split: This doesn’t touch Bitcoin’s consensus rules — everyone still agrees on what makes a valid block.
✅ Block size stays the same (~4 MB): This ensures that blockchain growth remains limited and sustainable.
✅ Alternative options exist: If you prefer the old limits, you can run Bitcoin Knots, which still enforces them.

Bottom line:

This is a software configuration change, not a change to Bitcoin’s fundamental rules. If you're using Bitcoin to store value or make payments, nothing about that has changed.

Bitcoin still enforces a ~100k virtual byte (kvB) standardness limit for most transactions (equivalent to 400,000 weight units), which helps mitigate spam and DoS attacks. For witness-heavy transactions, this can approach ~400kB in serialized size.


Common Uses of OP_RETURN


Timestamping documents
Cross-chain anchoring (e.g., merge-mined sidechains)
Asset issuance (e.g., Omni/Tether)
Notarization and digital certificates
Commitment schemes for external protocols (e.g., Citrea)


Note: Ordinal inscriptions and Stamps use witness data or fake outputs, not OP_RETURN.


The Change (PR #32359)


Bitcoin Core developers proposed removing the 80-byte OP_RETURN size cap.
The change also deprecates the -datacarrier and -datacarriersize options, with removal planned in future versions. This reflects an effort to consolidate node behavior and improve interoperability, though it reduces user-configurable relay control.
Larger OP_RETURN transactions would now be relayed and mined by default.


Why Remove the Limit? (Arguments For)


The cap is ineffective: Easily bypassed via:

Multi-output/multisig scripts
Witness data
Private miner APIs (e.g., MARA Slipstream)


Perverse incentives: Drives users to harmful alternatives that pollute the UTXO set.


Cleaner data: Encourages proper use of OP_RETURN rather than misusing spendable outputs. OP_RETURN outputs are prunable and do not enter the UTXO set — this is the cleanest way to embed data without long-term storage burdens.


Aligns with mining reality: Miners already include larger OP_RETURN transactions if their policies allow it.


Fee market is sufficient: Block size (4MB) + fee pressure limits abuse naturally.


Improves relay consistency: Nodes and miners share policy, improving block propagation and mempool estimation. While standardness rules don't prevent non-standard transactions from being mined, they raise the cost, delay inclusion, and reduce miner incentives — effectively discouraging misuse.


Reduces miner centralization: Some argue removing the limit spreads fee opportunities more evenly across miners. Others caution it may disadvantage miners who choose not to include such transactions — potentially reducing diversity. (i.e. purist miners (e.g., Ocean) may become less competitive if spam volume and revenue increases.)


Improves block relay performance: Removing artificial limits leads to fewer compact block reconstruction failures, reducing latency and making the network more resilient.


Enables better metaprotocol support: Clean OP_RETURN usage helps future protocols (e.g. Citrea, tokens, cross-chain anchoring) embed structured data safely without abusing spendable outputs.


Why Oppose the Change? (Arguments Against)


Encourages non-monetary use: Seen as shifting Bitcoin toward data storage.
Spam and bloat: Fear of more data-heavy protocols (e.g., inscriptions, stamps, NFTs) and “junk” data.
Undermines Bitcoin’s monetary purpose: Viewed as deviating from “sound money” principles.


Some argue that Bitcoin should remain minimal, focusing solely on censorship-resistant money — not general-purpose data storage.


Governance concerns:

Allegations of irregular PR handling
Claims of GitHub bans and manipulation
Some have noted that the change was poorly communicated — the initial feedback round may have been missed by the wider community, causing tension once the PR was submitted more formally.


Community dissent: Change was pushed despite vocal opposition from notable Bitcoiners and developers.


Note: “Inscriptions” technically refer to a specific Tapscript pattern used in Ordinals. Other methods like Stamps use different — and often more harmful — techniques.
Why this matters: Stamps are more harmful than inscriptions or OP_RETURN because they trick the network into storing data as if it were real, spendable bitcoin — permanently bloating the UTXO set, increasing node costs, and degrading performance


Weakens mempool-level spam resistance: Critics argue that filters play a vital role in making spam expensive and harder to propagate. Without such deterrents, spammers can bypass node filtering entirely via direct submission services (e.g., MARA Slipstream), further empowering large mining pools.


While miners are free to include any valid transaction in blocks, network-wide filters still raise the cost of abuse and protect the mempool from being flooded — as noted by Matt Hill (Start9):
“Filters can’t stop every attack, but they deter most and raise the cost of success. We should be adding filters, not removing them. All filters should be configurable. Power to the nodes.”


The Role of Configuration Options


Previously, miners could set:

-datacarrier=1 to allow OP_RETURN
-datacarriersize=X to raise the limit


Many private miners already raised these limits and mine such transactions.


Deprecating user-level control (e.g., -datacarrier, -datacarriersize) has sparked concerns about diminishing node sovereignty — even if such options had little practical impact in today's mining landscape.


Policy vs. Consensus: Why the 80-Byte Limit Causes Relay Inconsistency


The OP_RETURN size limit is a policy rule—not a consensus rule.
Miners/nodes can already mine/accept large OP_RETURN txs, and all nodes must still accept blocks containing them if they are valid under consensus rules (block size < 4MB).
This causes inconsistency between what gets relayed and what gets mined.

Today, many nodes won’t relay OP_RETURN transactions over 80 bytes, while miners using custom settings may still mine them. This creates an inconsistency: transactions not visible to most of the network can still end up in blocks. Removing the limit aligns what nodes relay with what miners accept, making mempools more consistent, block propagation faster, and fee estimates more reliable.
Some argue that removing the OP_RETURN cap weakens Bitcoin's built-in spam defenses. As Luke Dashjr noted, spam filters work collectively and are distinct from censorship — a block can always include any valid tx, but mempool filters help keep spam out before it gets that far.

Only ~30 non-standard OP_RETURN transactions have been mined out of 7 million in 2024, showing that standardness rules were a strong deterrent in practice.


Bitcoin Knots: A Protest Client

Bitcoin Knots (maintained by Luke Dashjr) retains the old 80-byte policy by default — in fact, it sets an even stricter default of 40 bytes for -datacarriersize. 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.


Implications


Bitcoin Governance: Highlights tension over who steers Bitcoin—developers, miners, users?
Network Fragmentation: Policy divergence leads to inconsistent mempool contents and complicates block propagation across nodes.
Market-driven moderation: Supporters argue fee markets, not hard-coded caps, should regulate block usage.
User Sovereignty: Running alternative clients (like Knots) is a check against centralization of development control.


Final Thoughts

This debate isn’t just about a technical tweak — it cuts to the heart of Bitcoin’s design: what it is for, who controls it, and how we preserve its neutrality:
What is Bitcoin for? Who decides how it evolves? And how do we protect user sovereignty?
Removing the OP_RETURN limit appears to be a technically sound cleanup that brings Core’s policy in line with how miners already operate. It improves relay consistency and encourages clean, prunable data over harmful workarounds. But it also reduces node configurability by deprecating -datacarriersize, and introduces new tradeoffs around block space usage, fee pressure, and miner incentives.

What nodes don’t relay rarely gets mined — and that’s why relay policy is policy.

While blocks are still capped at 4 MiB and consensus remains unchanged, this change underscores a deeper truth: Bitcoin's integrity depends not just on code correctness, but on who gets to shape that code and how.
If miners continue favoring pay-to-prioritize services (e.g., MARA Slipstream) over standard mempool flows, the removal of the cap may not reduce centralization as hoped. Instead, it may highlight the incentive distortions created by mining pool dominance — a more urgent challenge than OP_RETURN usage itself.
As Matthew Kratter noted:

“It's not that spam filters caused mining pool centralization — it's the reverse. Centralized pools make spam profitable.”

Ultimately, Bitcoiners must wrestle with the root problem:
How do we decentralize transaction selection in a world where relay policy, miner behavior, and mempool visibility are increasingly shaped by a handful of large actors?
The answer isn’t to freeze innovation or block all non-monetary use. It’s to protect choice.
👉 Run your own full node. Customize your policy. Choose your client.
This is where Bitcoin's sovereignty lies — and where its future will be decided.

Refs


PR: Remove arbitrary limits on OP_Return (datacarrier) outputs #32359
mailing list: Relax OP_RETURN standardness restrictions
youtube: Bitcoin Core Removes The Mask - by Matthew R. Kratter
gist: Retiring the 80-Byte OP_RETURN Limit
Bitcoin Knots
PR: Deprecate datacarrier options without removing them #32406
Q&A Compilation on OP_RETURN Policy Change (Stacker News) — curated answers to common concerns and misconceptions from the community debate
youtube: Bitcoin Spam and Mining Pool Centralization - by Matthew R. Kratter


🙏 Acknowledgements

Special thanks to @hodlinator for insightful and technically grounded feedback on:

The distinction between policy vs. consensus rules
Correcting OP_RETURN use case misconceptions (e.g., RSK, Lightning, inscriptions)
Emphasizing the ongoing role of transaction size limits for DoS mitigation
Clarifying miner centralization risks and block propagation realities
Improving phrasing around metaprotocols and node impact

Thanks also to ShiShi21m for surfacing the historical context from Bitcoin Core 0.9 — highlighting that OP_RETURN was originally introduced as a harm-reduction measure, not an endorsement of on-chain data storage.
Thanks to @murchandamus for technical corrections on Bitcoin Knots defaults and transaction size limits.
Additional thanks to all those who participated in the discussion — including critics — whose questions and objections helped clarify and refine key points.