Compiled by | GaryMa, WuBlockchain
Recently, @jeffrey_hu, Head of Investment Research at HashKey, thoroughly analyzed the background and controversy surrounding the Bitcoin Core proposal to remove the OP_RETURN limit. WuBlockchain has compiled and summarized the perspectives of relevant community members as follows.
Background: The OP_RETURN Data Limit Controversy
OP_RETURN is an opcode in Bitcoin’s scripting language that allows embedding small amounts of data in transactions. These outputs are provably unspendable, ensuring they do not burden the UTXO (Unspent Transaction Output) set. Currently, Bitcoin Core imposes a default 80-byte limit on OP_RETURN data, with a node policy (not a consensus rule) restricting the propagation of transactions exceeding 83 bytes.
Developer Peter Todd’s PR #32359 proposes removing this limit and eliminating related configuration options (e.g., `-datacarrier` and `-datacarriersize`), effectively preventing nodes from customizing these settings. This has sparked heated debate.
Perspectives
Supporters’ Views:
● The current limit is ineffective, as users can bypass it by submitting transactions directly to miners’ mempools (e.g., MARA Slipstream) or using unrestricted nodes (e.g., Libre Relay). For instance, the largest known OP_RETURN output reached 79,870 bytes.
● Some users treat the blockchain as a message board, with tools like opreturnbot.com facilitating data uploads for a fee.
● Removing the limit aligns with miners’ incentives, as they could earn more by competing for block space.
Opponents’ Views:
● Lifting the limit could lead to more non-transactional data (e.g., shitcoins) on the blockchain, crowding out block space and driving up fees.
● Although bypassable, node policies still serve a purpose by limiting the propagation of spam data, reducing network strain.
Detailed Perspectives
@0x_Todd (Nothing Research Partner): Supports removing the 80-byte limit, arguing it’s ineffective and that lifting it offers multiple benefits, including aligning with Bitcoin’s early design, reducing network strain, supporting ecosystem growth, boosting miner revenue, and upholding libertarian principles.
1. Classical Bitcoin Had No Limits
● In Satoshi Nakamoto’s era, OP_RETURN had no size restrictions.
● The 40-byte limit (later raised to 80 bytes) was introduced in 2014 to preserve Bitcoin’s “purity” as a ledger, not a data store.
● @0x_Todd believes removing the limit is a return to Satoshi’s original vision, not a deviation.
2. Current Limit Is Ineffective and Easily Bypassed
● The 80-byte limit is like a “10 cm fence,” easily circumvented via protocols like Inscriptions or Runes, which split data across multiple transactions, or unrestricted nodes like Libre Relay.
● Peter Todd, a top Bitcoin Core contributor and PR #32359 author, advocates for removing “paternalistic” relay policies, a stance @0x_Todd supports.
3. Reducing Network Strain from Inscriptions
● Inscriptions currently exploit loopholes (e.g., multi-transaction data storage), increasing network load.
● Removing the limit would allow direct OP_RETURN data storage, reducing unnecessary transactions.
● Note: Inscriptions are less popular now, making this a secondary argument.
4. Boosting Miner Revenue and Libertarian Ideals
● Lifting the limit could increase miner revenue, as seen in a 7MB “exploit” OP_RETURN block where the sender paid $3,600 in fees.
● @0x_Todd’s libertarian stance supports market-driven outcomes: if users pay and miners accept, restrictions are unnecessary.
● Additional benefit: With Bitcoin’s halving reducing rewards, larger OP_RETURN transactions could incentivize miners, enhancing network security.
@jeffrey_hu (HashKey Investment Research Lead): Leans against removing the limit, citing potential negative impacts (e.g., non-transactional data crowding block space) and emphasizing user freedom (retaining configuration options). He views the debate as ideological, with no clear right or wrong in the short term.
1. Satoshi’s Era Isn’t Always Relevant
● While OP_RETURN had no limits in Satoshi’s time, not all early designs remain suitable today, as evidenced by post-blocksize war changes.
● Citing Satoshi’s era alone isn’t sufficient justification.
2. Peter Todd’s Role and Bitcoin Core
● The proposal affects only Bitcoin Core, not the entire network.
● Todd’s “incentive-compatible” philosophy (e.g., Full-RBF) aligns with removing limits, but Bitcoin Core’s “paternalistic” removal of configuration options may curb user freedom.
3. Limited Impact on Inscriptions
● An 80-byte limit removal won’t significantly help Inscriptions, as 80 bytes is insufficient for large files but enough for BRC-20 JSON data (used for token issuance).
● People will exploit Bitcoin’s features (e.g., SegWit, Taproot) to issue tokens in “ugly” ways, regardless of limits.
4. Miner Revenue vs. User Freedom
● Miner revenue impacts are complex: increased fees are possible, but exclusive non-standard transaction services may lose value.
● While OP_RETURN is more elegant than Inscriptions (which create UTXO dust), user freedom matters more.
● As a node operator, @jeffrey_hu wants the choice to filter irrelevant data (e.g., message board content).
● He criticizes Bitcoin Core for removing configuration options, potentially forcing him to use Bitcoin Knots or transaction filters, though he sees this as potentially futile.
@crypcipher (UTXO Stack Founder): Supports lifting the limit, arguing that allowing direct data storage reduces the “wasteful” multi-transaction workarounds (e.g., ordinals) and UTXO dust.
@cyimonio (Fiamma Co-Founder): Opposes, arguing that some Bitcoin L2 projects using Bitcoin as a data availability (DA) layer are inefficient, akin to “spending big for small results.”
Consensus Rules vs. Node Policies
“If limits can be bypassed, are node restrictions still useful?”
Yes, but understanding this requires examining OP_RETURN, consensus rules, and node policies.
● OP_RETURN: An opcode that halts script execution and marks outputs as unspendable, a core consensus rule. Consensus rules only care about “unspendability,” not data size.
● Node Policies: These govern transaction handling:
● Pre-Chain: Nodes can restrict propagation of transactions exceeding 83 bytes, though valid transactions in new blocks are accepted to avoid forks.
● Post-Chain: Nodes can discard OP_RETURN data to reduce storage costs.
Potential Impacts and Suggestions
Positive Impacts: Increased miner revenue, support for Bitcoin ecosystem projects (e.g., Runes, Alkanes, sidechains).
Negative Impacts: Crowding out block space for regular Bitcoin users.
Miner Attitudes: Uncertain — block space competition could boost revenue, but exclusive non-standard transaction services may lose value.
Suggestions:
● If the PR passes and users disagree, they can run stricter clients (e.g., Bitcoin Knots) or older versions.
● Reassess Bitcoin Core’s role in balancing security patches, node policies, and consensus rules, and choose clients aligning with personal philosophies.
References:
https://x.com/jeffrey_hu/status/1917491946609860991
https://x.com/0x_Todd/status/1917889200684454340
https://x.com/jeffrey_hu/status/1917970887917343184
Follow us
Twitter: https://twitter.com/WuBlockchain
Telegram: https://t.me/wublockchainenglish