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.
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).
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.
- ✅ 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.
- 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
-datacarrierand-datacarriersizeoptions. - Larger
OP_RETURNtransactions would now be relayed and mined by default.
-
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.
-
Aligns with mining reality: Many miners already mine larger OP_RETURN txs.
-
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.
-
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.
-
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.
-
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.
-
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
-
Previously, miners could set:
-datacarrier=1to allow OP_RETURN-datacarriersize=Xto raise the limit
-
Many private miners already raised these limits and mine such transactions.
- 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 (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.
- 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.
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.
- 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
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.
Thanks for doing your take on this!
I know you mention it earlier, but maybe still highlight here that it was limited on a policy level, not consensus?
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.
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.
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
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