Bitcoin OP_RETURN Controversy: Complete Summary (May 6 2025)

op_return_controversy_summary.md

Bitcoin OP_RETURN Controversy: Complete Summary

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 ~100KB transaction size limit, which mitigates abuse and remains unchanged.

---

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 removes the -datacarrier and -datacarriersize options.
• Larger OP_RETURN transactions would now be relayed and mined by default.

---

Why Remove the Limit? (Arguments For)

1. The cap is ineffective: Easily bypassed via:

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

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

3. Cleaner data: Encourages proper use of OP_RETURN rather than misusing spendable outputs.

4. Aligns with mining reality: Many miners already mine larger OP_RETURN txs.

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

6. Improves relay consistency: Nodes and miners share policy, improving block propagation and mempool estimation.

7. Reduces miner centralization: If only some miners accept large OP_RETURN transactions, they gain a fee advantage, encouraging hashers to consolidate into those pools. Removing the limit spreads opportunity evenly across miners.

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

9. 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)

1. Encourages non-monetary use: Seen as shifting Bitcoin toward data storage.

2. Spam and bloat: Fear of more data-heavy protocols (e.g., inscriptions, stamps, NFTs) and “junk” data.

3. Undermines Bitcoin’s monetary purpose: Viewed as deviating from “sound money” principles.

4. 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.

5. 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

---

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.

---

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.

---

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.

---

Implications

• Bitcoin Governance: Highlights tension over who steers Bitcoin—developers, miners, users?
• Network Fragmentation: Policy divergence causes inconsistent mempools and block propagation issues.
• 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 is not just about a technical parameter, but about the philosophical and practical boundaries of Bitcoin’s design—what it is for, how it evolves, and who gets to decide. Removing the OP_RETURN limit may not break consensus, but it has catalyzed a cultural and political rift that could shape Bitcoin’s future.

Removing the OP_RETURN limit is a technically sensible cleanup that aligns policy with reality, but it raises deeper concerns about Bitcoin's purpose, governance, and resistance to non-monetary use.

This episode also highlights growing interest in improving node privacy and resilience — from AS-level network mapping (ASMap) to proposals for better tools to defend against surveillance or eclipse attacks.

---

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

---

🙏 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 (Nostr: npub1ugnq57hn8va6xqr5zywy2eunem6c624583vkt0dmv40ep7tnnxkqrr898l) 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.

Additional thanks to all those who participated in the discussion — including critics — whose questions and objections helped clarify and refine key points.

Relevant code paths

Bitcoin Core

https://github.com/bitcoin/bitcoin/blob/v29.0/src/policy/policy.h#L75-L79
https://github.com/bitcoin/bitcoin/blob/v29.0/src/init.cpp#L638-L641

Bitcoin Knots

https://github.com/bitcoinknots/bitcoin/blob/v28.1.knots20250305/src/init.cpp#L814

Thanks for doing your take on this!

It was limited to 80 bytes to discourage non-payment data usage while still allowing basic use cases (e.g., hashes, commitments).

I know you mention it earlier, but maybe still highlight here that it was limited on a policy level, not consensus?

Common Uses of OP_RETURN
...

• NFT metadata and inscriptions
• Smart contract coordination (e.g., RSK, Lightning)

It is not used for inscriptions AFAIK, they use witness data. You include a quote saying as much further down under "Community dissent".
RSK uses the coinbase transaction AFAIK, so it is up to the miner and not subject to policy. See the "RSKBLOCK" output in: https://mempool.space/tx/e29b05f098fc230177a3b6b5fd77d2f94136e59cb4a7e46e3b7ab683180fbdd5
I'm 99% sure Lightning does not use OP_RETURN for anything.

7. Reduces miner centralization: If only some miners accept large OP_RETURN transactions, they gain a fee advantage, encouraging hashers to consolidate into those pools. Removing the limit spreads opportunity evenly across miners.

Keeping the policy limit also encourages use of transaction accelerators such as MARA's Slipstream. These pool-operated ways around policy are able to pay an out-of-bound fee to pool-operators, which they may or may not pass down to hashers (pool-participating miners). This is a further centralization pressure.

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

MARA have been taking it one step further by experimenting with a custom implementation of block template construction, which at least once lead to mining consensus-invalid blocks (rejected by the rest of the network): https://x.com/MARAHoldings/status/1707067548661928108

Enables better metaprotocol support: ...

I would phrase this as "Enables less harmful metaprotocol support". Haven't seen any regular Bitcoin Core devs advocating for enabling shitcoins on Bitcoin. I thinks that's malicious mischaracterization from the other side. Lopp is highly technical but not a regular contributor.

---

It would be interesting to include a section on whether filtering of OP_RETURNs today actually has any substantial effect on the contents of blocks. I know OCEAN sometimes mines blocks that have less spam in them, but that's a very ephemeral win. If there is any substantial effect, I wonder if that effect is to incentivize people to use witness data instead, which is more harmful to nodes.

Might be worth noting that there's still a transaction size limit of 100KB or so that nobody is proposing to change at this point AFAIK. Having that limit is a DoS mitigation for the network, so there's a technical reason to keep it.

There is also a milder version of bitcoin/bitcoin#32359 which deprecates the setting without removing it: bitcoin/bitcoin#32406

Saw this posted by Anita Posch:
https://youtu.be/xYbakpGY9Ys?feature=shared&t=600
Arguably it's from the geographical heart of shitcoins (San Fransisco), but might be worth a watch. They do claim the UTXO set is all kept in memory, which I believe is false, we flush less recently used ones to disk. Growing the UTXO-set primarily has an impact on disk space for nodes. It also affects seek time when looking up flushed UTXOs, but it's O(log N)-complexity AFAIK.

The way in which this change was proposed was unfortunate. Ideally we should hash it out with the wider community up front to assuage fears. Arguably it was posted as more of a "Request for Feedback" form by Antoine Poinsot (regular contributor) initially before being implemented as a pull request by Peter Todd (less regular contributor). I suspect the first one was mostly ignored by the wider community, while the second one was what set things on fire.

The decentralization of the network is one of Bitcoin's strengths. I'm surprised and partially troubled to see so much outrage. Having such an immune system is vital, but in this specific case we have caught an auto-immune disease.

Anyway, I should probably write my own post in a more structured way somewhere. But maybe you could incorporate some of the feedback from the beginning?

Cheers,
Fairly regular but more recent Bitcoin Core dev

Ironically, any dissenting voices are ignored or blocked by Core Devs on this topic. However, Core Devs welcome any form on spam to reside permanently on the Bicoin blockchain for all eternity.

The OP_RETURN opcode was specifically designed with an 80-byte limit to allow minimal arbitrary data storage while preventing blockchain bloat. Without size restrictions, the blockchain will become filled with large amounts of non-financial data, increasing storage requirements for all nodes. Full nodes would need to store, validate, and propagate significantly more data, increasing hardware requirements and thereby making the bitcoin network more centralized.

Bitcoin's fee market is designed for financial transactions, large data storage via OP_RETURN could compete with financial transactions for block space. It would effectively subsidize data storage applications at the expense of the network's primary purpose.

In addition, larger OP_RETURN sizes make it cheaper to flood the network with data. Larger script sizes could increase transaction validation time.

Not to mention, changing fundamental limitations could introduce subtle consensus bugs. I don't think this has been thought through.

Ironically, any dissenting voices are ignored or blocked by Core Devs on this topic.

Devs have directed less technical objections to other forums than pull requests, such as the mailing list. Agree that the moderation tools provided by GitHub give a somewhat despotic impression when used.

The OP_RETURN opcode was specifically designed with an 80-byte limit to allow minimal arbitrary data storage while preventing blockchain bloat. Without size restrictions, the blockchain will become filled with large amounts of non-financial data, increasing storage requirements for all nodes.

If we see an increase in OP_RETURN data, it will leave less space for witness inscription spam, thereby decreasing the overall size of the block, leading to decreased storage requirements.

Full nodes would need to store, validate, and propagate significantly more data, increasing hardware requirements and thereby making the bitcoin network more centralized.

Bitcoin still has fixed block size limits (1MB non-witness data + 4MB including witness data). Assuming Bitcoin adoption increases, we will always see relatively full blocks.

Bitcoin's fee market is designed for financial transactions, large data storage via OP_RETURN could compete with financial transactions for block space. It would effectively subsidize data storage applications at the expense of the network's primary purpose.

OP_RETURNS don't get the witness discount, so one could say financial transactions are more subsidized per byte in this respect.

In addition, larger OP_RETURN sizes make it cheaper to flood the network with data. Larger script sizes could increase transaction validation time.

OP_RETURNS only carry data and are therefore less costly to validate per byte.

Not to mention, changing fundamental limitations could introduce subtle consensus bugs. I don't think this has been thought through.

As noted in the gist above, the change is just about mempool policy, not consensus. You are correct, someone needs to think this through. Try actually reading and addressing the above points instead of brigading.

Thanks for doing your take on this!

It was limited to 80 bytes to discourage non-payment data usage while still allowing basic use cases (e.g., hashes, commitments).

I know you mention it earlier, but maybe still highlight here that it was limited on a policy level, not consensus?

Common Uses of OP_RETURN
...

• NFT metadata and inscriptions
• Smart contract coordination (e.g., RSK, Lightning)

It is not used for inscriptions AFAIK, they use witness data. You include a quote saying as much further down under "Community dissent". RSK uses the coinbase transaction AFAIK, so it is up to the miner and not subject to policy. See the "RSKBLOCK" output in: https://mempool.space/tx/e29b05f098fc230177a3b6b5fd77d2f94136e59cb4a7e46e3b7ab683180fbdd5 I'm 99% sure Lightning does not use OP_RETURN for anything.

7. Reduces miner centralization: If only some miners accept large OP_RETURN transactions, they gain a fee advantage, encouraging hashers to consolidate into those pools. Removing the limit spreads opportunity evenly across miners.

Keeping the policy limit also encourages use of transaction accelerators such as MARA's Slipstream. These pool-operated ways around policy are able to pay an out-of-bound fee to pool-operators, which they may or may not pass down to hashers (pool-participating miners). This is a further centralization pressure.

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

MARA have been taking it one step further by experimenting with a custom implementation of block template construction, which at least once lead to mining consensus-invalid blocks (rejected by the rest of the network): https://x.com/MARAHoldings/status/1707067548661928108

Enables better metaprotocol support: ...

I would phrase this as "Enables less harmful metaprotocol support". Haven't seen any regular Bitcoin Core devs advocating for enabling shitcoins on Bitcoin. I thinks that's malicious mischaracterization from the other side. Lopp is highly technical but not a regular contributor.

It would be interesting to include a section on whether filtering of OP_RETURNs today actually has any substantial effect on the contents of blocks. I know OCEAN sometimes mines blocks that have less spam in them, but that's a very ephemeral win. If there is any substantial effect, I wonder if that effect is to incentivize people to use witness data instead, which is more harmful to nodes.

Might be worth noting that there's still a transaction size limit of 100KB or so that nobody is proposing to change at this point AFAIK. Having that limit is a DoS mitigation for the network, so there's a technical reason to keep it.

There is also a milder version of bitcoin/bitcoin#32359 which deprecates the setting without removing it: bitcoin/bitcoin#32406

Saw this posted by Anita Posch: https://youtu.be/xYbakpGY9Ys?feature=shared&t=600 Arguably it's from the geographical heart of shitcoins (San Fransisco), but might be worth a watch. They do claim the UTXO set is all kept in memory, which I believe is false, we flush less recently used ones to disk. Growing the UTXO-set primarily has an impact on disk space for nodes. It also affects seek time when looking up flushed UTXOs, but it's O(log N)-complexity AFAIK.

The way in which this change was proposed was unfortunate. Ideally we should hash it out with the wider community up front to assuage fears. Arguably it was posted as more of a "Request for Feedback" form by Antoine Poinsot (regular contributor) initially before being implemented as a pull request by Peter Todd (less regular contributor). I suspect the first one was mostly ignored by the wider community, while the second one was what set things on fire.

The decentralization of the network is one of Bitcoin's strengths. I'm surprised and partially troubled to see so much outrage. Having such an immune system is vital, but in this specific case we have caught an auto-immune disease.

Anyway, I should probably write my own post in a more structured way somewhere. But maybe you could incorporate some of the feedback from the beginning?

Cheers, Fairly regular but more recent Bitcoin Core dev

Thanks so much for the thoughtful feedback!

You’re absolutely right on several key points — especially highlighting that the 80-byte OP_RETURN cap was a policy rule, not a consensus rule. I’ve revised the gist to clarify that early on.

Also appreciate the corrections on usage examples — you’re right that inscriptions use witness data, and RSK uses the coinbase, not OP_RETURN. I've updated that section to reflect those distinctions more accurately.

I also really liked your point about the ~100KB transaction size limit — it's a clear and concrete way to show that important DoS protections remain in place, regardless of OP_RETURN policy.

Finally, I completely agree that the way this change surfaced caused more friction than it needed to. Your autoimmune metaphor really captures the dynamic perfectly.

Thanks again — this kind of constructive, good-faith input is exactly what helps Bitcoin remain robust and self-correcting. 🙏

Updated with the Historical Context: Why OP_RETURN Was Introduced (Bitcoin Core 0.9, March 2014) section.

Thanks for incorporating most of my suggestions!

• According to Matthew R. Kratter, Bitcoin Knots nodes surpassed Core's latest version in early 2025

That twitter post in the video is comparing a Knots release from what looks like the beginning of March to the latest Core 29.0 release that was released in mid-April (link with time: https://youtu.be/PaAjhhkFjU8?t=385). That's some disingenuous framing. My most regular node is probably still running Core 28.x or earlier. I think it's good that this node-switching drill happened, and hopefully Core in time will earn back some users who don't want to rely on only one single dev for their node software. Kratter also frames it as the change already having been made. I think it is a bit disrespectful to make out devs which you relied on for years as clowns, farming engagement.

Interesting to see Mow's hot twitter takes in the above video. Would be cool if we made sharing of banned nodes dynamic, or if people shared banlist.json-files for blocking Chainalysis clearnet-nodes (probably not worth it trying to ban Tor addresses as they can be easily generated). It would be necessary to think about the risk of eclipse attacks when limiting connectivity. Also we would be poking the Chainalysis bear and forcing them to adapt, maybe switching to services with broad IP-ranges that are reused among all customers if they aren't doing that already. There is ongoing (but in need of help!) work on ASMap to make Core aware of nodes on an Anonymous System network level. One could also add some kind of plugin support for custom filtering of transactions, but not sure we want that maintenance burden.

Thanks for incorporating most of my suggestions!

• According to Matthew R. Kratter, Bitcoin Knots nodes surpassed Core's latest version in early 2025

That twitter post in the video is comparing a Knots release from what looks like the beginning of March to the latest Core 29.0 release that was released in mid-April (link with time: https://youtu.be/PaAjhhkFjU8?t=385). That's some disingenuous framing. My most regular node is probably still running Core 28.x or earlier. I think it's good that this node-switching drill happened, and hopefully Core in time will earn back some users who don't want to rely on only one single dev for their node software. Kratter also frames it as the change already having been made. I think it is a bit disrespectful to make out devs which you relied on for years as clowns, farming engagement.

Interesting to see Mow's hot twitter takes in the above video. Would be cool if we made sharing of banned nodes dynamic, or if people shared banlist.json-files for blocking Chainalysis clearnet-nodes (probably not worth it trying to ban Tor addresses as they can be easily generated). It would be necessary to think about the risk of eclipse attacks when limiting connectivity. Also we would be poking the Chainalysis bear and forcing them to adapt, maybe switching to services with broad IP-ranges that are reused among all customers if they aren't doing that already. There is ongoing (but in need of help!) work on ASMap to make Core aware of nodes on an Anonymous System network level. One could also add some kind of plugin support for custom filtering of transactions, but not sure we want that maintenance burden.

Thanks again — really appreciate your follow-up!

You're absolutely right about the Knots node count comparison in Kratter’s video — it was likely just a timing mismatch between releases. I’ve updated the Gist to reflect that context and clarified that the spike was more of a coordinated protest than a fundamental shift in user preference.

Also fully agree on not turning disagreement into character attacks. It’s easy to get swept up in narratives, but it’s important we stay focused on the ideas, especially when the people involved have spent years strengthening the project.

Let me know if you spot anything else worth adjusting — your feedback continues to be incredibly helpful.

---

Sidenote: As of May 8, 2025, Knots 20250305 represented ~5.8% of nodes, while Core 29.0.0 was close behind at ~5.3%, according to Clark Moody’s dashboard.

Published on Nostr https://primal.net/a/naddr1qp992mnyv4e8xarpdejxjmn8946xsefdgf5hgcm0d9hz6n6s94fy24z42f8z6sm0de68ymmkv4e8x7fd2phkc6tr0ykhvuedgdhkuum9deeh2uedd36xkdtkxypzpmx6gv5vpwujnj3gtfp8vt60lltr956cafyyrl9hgf9hzqf83urjqvzqqqr4gufenlsm