Debate Intensifies Within Bitcoin Core Community Over OP_RETURN Data Size Limit
Recently, the debate regarding whether to remove the OP_RETURN data size limit within the Bitcoin Core community has intensified. This article consolidates various perspectives, analyzes the background of the proposal, technical details, and philosophical controversies, assisting readers in comprehensively understanding this critical technical discussion.
(Background: Bitcoin’s market share has approached 65%, reaching a four-year high. Is the altcoin season approaching?)
(Supplementary Background: Bitcoin Foundation elder statesman: Striving to restart the free BTC faucet, 21million.com is now online.)
Recently, HashKey’s Head of Investment Research, @jeffrey_hu, detailed the background and controversies surrounding the Bitcoin Core proposal “Remove OP_RETURN Data Limit.” Wu has compiled and integrated the viewpoints of relevant community members, which are summarized as follows.
Background: Controversy Over OP_RETURN Data Limit
OP_RETURN is an opcode in Bitcoin script used to embed a small amount of data within Bitcoin transactions. It allows users to store data on the blockchain, but these outputs are “provably unspendable,” thus not increasing the burden on the UTXO (unspent transaction output) set.
The current default limit in Bitcoin Core is 80 bytes for OP_RETURN data, and there is a node policy (rather than a consensus rule) that limits the propagation of OP_RETURN transactions larger than 83 bytes.
Core developer Peter Todd proposed PR #32359, suggesting the removal of this limit while simultaneously eliminating related configuration options (such as -datacarrier and -datacarriersize), effectively cutting off the nodes’ hope for self-configuration, which has triggered intense discussions.
Perspectives
Supporters’ View:
- The current limit is ineffective, as it can be bypassed by directly submitting to the miner mempool (e.g., MARA Slipstream) or through unrestricted nodes (e.g., Libre Relay). (For instance, the largest known OP_RETURN output reached 79,870 bytes).
- Some users even use OP_RETURN to treat the blockchain as a message board. There are also tools to help package data on-chain (opreturnbot.com), available for a fee.
- Removing the limit may align better with miner incentives, as miners could earn more revenue by competing for block space.
Opponents’ View:
- Removing the limit would lead to more non-transactional data being written onto the chain (e.g., shitcoins), occupying block space and raising transaction fees.
- Although the limit can be circumvented, node policies remain useful (e.g., limiting propagation reduces garbage data pressure on the network).
Furthermore, developer Luke Dashjr has previously stated that this proposal is “utter insanity.” He believes that relaxing OP_RETURN limits would allow more “garbage data” to be embedded in the blockchain, potentially leading to blockchain bloat, rising transaction fees, and undermining Bitcoin’s core mission as a “network currency.”
Collection of Individual Detailed Perspectives:
Nothing Research Partner @0x_Todd: Supports the removal of the 80-byte OP_RETURN data limit, arguing that the current limitation is ineffective and that lifting it could yield multiple benefits, including a return to Bitcoin’s early design, reduced network burden, support for ecological development, increased miner revenue, and alignment with libertarian ideals.
- 1. No Limit in Satoshi’s Era, Returning to the Classics: In Satoshi’s era (early Bitcoin), OP_RETURN had no byte limitations. In 2014, Bitcoin introduced a 40-byte limit (later raised to 80 bytes) to maintain Bitcoin’s “purity” (for bookkeeping rather than data storage). 0x_Todd believes removing the 80-byte limit is not “heretical,” but rather a return to the classical design of Satoshi’s era, aligning with Bitcoin’s original spirit.
- 2. Current Limit is Ineffective and Easily Bypassed: The current 80-byte limit is essentially meaningless, akin to a “10-centimeter high fence,” failing to prevent users from storing large data. Bypassing methods include using inscriptions, runes, and other protocols to store data through multiple transactions. Bypassing node policies, such as using the Libre Relay client (whose slogan is “Eliminating paternalism in Bitcoin Core’s relay policy”). Peter Todd, the proposer of PR #32359, is one of the core developers of Bitcoin Core, ranking among the top ten contributors; supporting the removal of the limit reflects “anti-paternalism” and is worthy of support.
- 3. Reducing Network Burden from Inscriptions: Inscriptions currently store data by “bugging” the system (e.g., circumventing the 80-byte limit through multiple transactions), adding to network burden. Removing the 80-byte limit would allow inscriptions to store data directly through OP_RETURN, reducing unnecessary multiple transactions and alleviating network pressure. Additional note: Inscriptions are currently unpopular, so this reasoning is merely a “side note” (a minor reason).
- 4. Providing Additional Income for Miners, Aligning with Libertarianism: Removing the limit can bring additional revenue to miners. For example, 0x_Todd mentioned a 7MB “super bug” OP_RETURN block where the sender paid $3,600 in fees. This indicates the market demand’s authenticity: someone is willing to pay to store large data on-chain, and miners are willing to package it. 0x_Todd, holding a libertarian position, believes that such “market-driven” behavior (voluntary exchanges) should not be restricted, and hard interventions are meaningless. Additional benefit: As Bitcoin undergoes halving every four years, leading to reduced miner income, allowing large OP_RETURN transactions can increase revenue, incentivizing miners to continue contributing computational power, thereby securing the Bitcoin network.
HashKey’s Head of Investment Research @jeffrey_hu: Leans against removing the 80-byte OP_RETURN data limit. He believes removing the limit may have negative impacts (e.g., non-transactional data occupying block space) and strongly emphasizes the importance of user freedom (retaining configuration options). He believes the support and opposition stem more from ideological differences, with no absolute right or wrong in the short term. In response to @0x_Todd’s four points, he elaborated on his views:
- 1. No Limit in Satoshi’s Era Does Not Mean It’s Rational: Although there were no limits in Satoshi’s era, not all of Satoshi’s designs were reasonable; many early designs later proved problematic (e.g., some modifications before and after the block wars). One cannot simply support the removal of limits by citing “there were no limits in Satoshi’s era”; Satoshi’s designs are not necessarily applicable today.
- 2. Peter Todd’s Position and Bitcoin Core’s Role: The removal of limits is merely a proposal from the Bitcoin Core client, not a decision for the entire Bitcoin network. Peter Todd is a senior developer whose ideology leans towards “incentive compatibility” (similar to Full-RBF logic: preventing gentlemen but not scoundrels); his proposal to remove the limit aligns with his style, but it is not unexpected. Bitcoin Core’s “paternalistic” approach (e.g., removing configuration options) is worth discussing, as it may restrict user freedom.
- 3. Limited Significance of Inscriptions Issue Post-Limit Removal: Removing the 80-byte limit offers limited help for inscriptions. 80 bytes are insufficient to store large files (e.g., images), but adequate to allow the BRC-20 protocol to write JSON data (used for issuing tokens). Even if Bitcoin provides powerful functions (e.g., one-time seals, SegWit), there will always be those who will issue tokens on-chain in the “ugliest” way; lifting the limit does not fundamentally resolve this issue.
- 4. Miner Revenue vs. Libertarianism: User Freedom is More Important: The impact on miner revenue is complex (it may increase revenue but might also harm the “exclusive service” advantage of mining pools). Supporting libertarianism: users have the right to pay to go on-chain; storing data through OP_RETURN is more elegant than inscriptions (two transactions + increased UTXO dust). However, there is a strong emphasis on user freedom: as a full node operator, he needs the freedom to choose whether to propagate this data (e.g., message board content unrelated to him). Criticism of Bitcoin Core for removing configuration options (e.g., -datacarriersize and Full-RBF configuration) deprives users of choice. If Bitcoin Core does not provide this freedom, he may switch to Bitcoin Knots or add transaction filters, but he believes this approach may be “like trying to stop a train” (futile).
UTXO Stack founder @crypcipher: Supports the removal of the limit, arguing that it is better to open access directly than to allow circumvention. He mentioned that protocols like ordi write data exceeding 80 bytes through multiple transactions; removing the limit could reduce such “ineffective efforts” and UTXO dust.
Fiamma co-founder @cyimonio: Opposes, arguing that some Bitcoin L2 projects (like storing state data on Bitcoin) merely treat Bitcoin as a data availability (DA) layer, which is of little significance and amounts to “spending a lot for trivial matters.”
Consensus Rules and Node Policies
“If it can be bypassed, then do node restrictions still matter?”
Yes, they are useful, but to understand this issue, we must start from OP_RETURN and the “consensus rules” and “node policies” it involves. OP_RETURN is an opcode in the Bitcoin scripting language, whose function is to immediately terminate the execution of the script and mark that output as “provably unspendable.”
The behavior of OP_RETURN (terminating script execution and marking output as unspendable) is a core rule of the Bitcoin protocol, belonging to consensus rules. Consensus rules only care about “whether it is unspendable,” without regard to the specific size of accompanying data. The limitation on the specific size of data accompanying OP_RETURN, however, falls under node policy. Nodes can do quite a bit, as they can decide how to handle the transaction data they receive.
- Before On-chain: Before a block is packed, restrictions can be applied regarding whether this transaction can be propagated in the P2P network. Bitcoin Core previously did not propagate OP_RETURN transactions larger than 83 bytes, but if such transactions exist in a new block, since they comply with consensus rules, nodes will also recognize that transaction as valid, and the chain will not fork.
- After On-chain: Nodes can also take action, such as automatically discarding data accompanying OP_RETURN, reducing their storage costs.
Possible Impacts and Recommendations
- Positive: May increase miner revenue and support Bitcoin ecological projects (e.g., Runes, Alkanes, and sidechains).
- Negative: Could crowd out block space for regular Bitcoin users.
- Uncertain Attitude from Miners: On one hand, increased competition for block space may raise revenue; on the other hand, mining pools may not favor it, as the “exclusive service” advantage of packaging non-standard transactions would diminish.
Personal Recommendation: If the PR passes but users dislike it, they can choose to run clients with stricter restrictions (like Bitcoin Knots) or older versions. Reassess the role of Bitcoin Core (balancing between security updates, node policies, and consensus rules) and consider choosing clients that align better with individual ideals.
Reference Links:
