Bitcoin Controversial Proposal: OP_RETURN Data Limit, A Return to Freedom or Increased Congestion?

Written by: @jeffrey_hu

Compiled by: GaryMa, Wu Says Blockchain

Recently, HashKey's investment research director @jeffrey_hu detailed the background and controversies surrounding the Bitcoin Core proposal "Remove OP_RETURN Data Limit." Wu summarized and integrated the views of relevant community members, compiled as follows.

Background Analysis: Controversy over OP_RETURN Data Limitations

OP_RETURN is an opcode in the Bitcoin script used to embed a small amount of data in Bitcoin transactions. It allows users to store data on the blockchain, but these outputs are "provably unspendable," thus not adding to the burden of the UTXO (unspent transaction output) set. The current default limit in Bitcoin Core is that the OP_RETURN data size is 80 bytes, and there is a node policy (rather than a consensus rule) that limits the propagation of OP_RETURN transactions larger than 83 bytes.

Developer Peter Todd proposed PR #32359, suggesting the removal of this restriction and simultaneously deleting related configuration options (such as -datacarrier and -datacarriersize), effectively cutting off the nodes' hope for self-configuration, which sparked intense discussion.

Viewpoint sorting

Supporters' views:

Current limitations are ineffective because they can be bypassed by directly submitting to the miner's mempool (such as MARA Slipstream) or through unrestricted nodes (such as Libre Relay). (For example, the known maximum OP_RETURN output reaches 79,870 bytes).

Some users even use OP_RETURN to turn the chain into a message board. There are also tools to help package on-chain (opreturnbot.com), as long as you pay the fees.

Removing restrictions may be more compatible with miner incentives, as miners can earn more income by competing for block space.

Opponents' viewpoint:

Removing restrictions will lead to more non-transaction data being written to the chain (such as shitcoin), crowding block space and driving up transaction fees.

Although restrictions can be circumvented, node policies are still useful (e.g., limiting propagation and reducing the pressure of junk data on the network).

Personal detailed opinions collection:

Nothing Research Partner @0x_Todd: Supports the removal of the 80-byte data limit on OP_RETURN, believes the current limit is ineffective, and that removing the limit can bring multiple benefits, including a return to Bitcoin's early design, reducing network burden, supporting ecological development, increasing miner income, and aligning with liberal ideals.

1. The Satoshi era is unlimited, returning to the classical.

In the Satoshi Nakamoto era (early Bitcoin), OP_RETURN had no byte limit.

In 2014, Bitcoin introduced a 40-byte limit (later increased to 80 bytes) with the aim of maintaining the "purity" of Bitcoin (for accounting rather than data storage).

0x_Todd believes that removing the 80-byte limit is not "heretical" but rather a return to the classical design of Satoshi's era, aligning with the original spirit of Bitcoin.

2. Current restrictions are invalid and can be easily bypassed.

The current 80-byte limit is essentially meaningless, resembling a "10 cm high fence wall," which cannot prevent users from storing large-sized data.

Ways to bypass 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 "Eliminate paternalism in Bitcoin Core relay policies"). Peter Todd (the proposer of PR #32359) is one of the core developers of Bitcoin Core, ranked among the top ten contributors, and supporting the removal of restrictions is a manifestation of "de-paternalism," which is worth supporting.

3. Reduce the burden of inscriptions on the network

Inscriptions currently store data through the "Card Bug" method (for example, bypassing the 80-byte limit through multiple transactions), increasing the network burden.

After removing the 80-byte limit, inscriptions can directly store data through OP_RETURN, reducing unnecessary multiple transactions and lowering the pressure on the network.

Additional note: Inscriptions are no longer popular, so this reason is just a "fluff" (minor reason).

4. Provide additional income for miners, in line with liberalism.

Removing restrictions can bring additional income to miners.

For example: 0x_Todd mentioned a "super large card bug" OP_RETURN block of 7 MB, where the sender paid a fee of $3,600.

This indicates the authenticity of market demand: there are people willing to pay for large-sized data to be put on the blockchain, and miners are willing to package it.

0x_Todd holds a liberal stance, believing that such "market determination" behavior (mutual consent) should not be restricted, and that rigid intervention is meaningless.

Additional benefits: With Bitcoin's halving every four years, miner income decreases, allowing for larger OP_RETURN transactions to increase revenue, incentivizing miners to continue investing in hashing power and solidifying the security of the Bitcoin network.

HashKey Investment Research Director @jeffrey_hu: Leans against removing the 80-byte data limit on OP_RETURN. He believes that removing the limit may have negative impacts (e.g., non-transactional data occupying block space), while emphasizing the importance of user freedom (retaining configuration options). He thinks that the support and opposition are more about ideological differences, with no absolute right or wrong in the short term. In response to @0x_Todd's four arguments, he elaborates his views correspondingly:

1. The era of Satoshi Nakamoto is unlimited, but that does not mean it is reasonable.

In the era of Satoshi Nakamoto, OP_RETURN had no restrictions, but not all of Satoshi's designs were reasonable; many early designs were later proven to have issues (such as some modifications before and after the block wars).

One cannot simply use "the unlimited era of Satoshi Nakamoto" as a reason to support lifting restrictions; Satoshi's design may not necessarily apply to the present.

2. Peter Todd's stance and the role of Bitcoin Core

The lifting of restrictions is merely a proposal from the Bitcoin Core client, not a decision made by the entire Bitcoin network.

Peter Todd is a senior developer whose philosophy leans towards "incentive compatibility" (similar to the logic of Full-RBF: preventing gentlemen but not small villains). He proposed removing restrictions in line with his style, but it's not surprising.

The "parental" approach of Bitcoin Core (such as removing configuration options) is worth discussing as it may restrict user freedom.

3. Inscription issue: Canceling restrictions has limited significance.

Removing the 80-byte limit has limited benefits for inscriptions.

80 bytes is not enough to store large files (such as images), but it is sufficient for the BRC-20 protocol to write JSON data (for token issuance).

Even though Bitcoin offers powerful features (such as one-time seals and SegWit), there will always be people who issue coins on-chain in the "ugliest" way, and lifting restrictions does not fundamentally solve this problem.

4. Miner Income and Liberalism: User Freedom is More Important

The impact of miner income is complex (it may increase income, but it may also harm the "exclusive service" advantage of mining pools).

Support Liberalism: Users have the right to pay to go on-chain, and OP_RETURN storing data is more elegant than inscriptions (two transactions + increasing UTXO dust).

But it emphasizes user freedom: as a full node operator, he needs the freedom to choose whether to propagate this data (for example, the content of the message board is irrelevant to him).

Criticism of Bitcoin Core's removal of configuration options (such as -datacarriersize and Full-RBF configuration) has deprived users of choice.

If Bitcoin Core doesn't offer this freedom, he may switch to Bitcoin Knots or add a transaction filter, but thinks this may be a "mantis arm" (in vain).

UTXO Stack founder @crypcipher: supports lifting restrictions, believing it is better to open it up directly than to let people circumvent it. Mentioned that protocols like ordi write over 80 bytes of data through multiple transactions, and removing restrictions can reduce this "futile work" and UTXO dust.

Fiamma Co-Creator @cyimonio: Opposed, arguing that some Bitcoin L2 projects (such as storing state data on Bitcoin) just use Bitcoin as a data availability (DA) layer, which is meaningless and belongs to "spending a lot of money to do small things".

Consensus rules and node policies

"Since it can be bypassed, is the node restriction still useful?"

It's useful, but to understand this issue, we still need to start from OP_RETURN and the "consensus rules" and "node policies" it involves.

OP_RETURN is an opcode in the Bitcoin scripting language that immediately terminates the execution of the script and marks the output as "provably unspendable."

The behavior of OP_RETURN (which terminates script execution and marks the output as unspendable) is a core rule of the Bitcoin protocol and is part of the consensus rules. The consensus rules only care about "whether it is unspendable," and not about the specific size of the accompanying data.

The specific size limit for the data attached to OP_RETURN falls under node policy. Nodes can do quite a bit because they can decide how to handle the transaction data they receive.

Before being on the chain: Restrictions are placed on whether this transaction can propagate in the P2P network before the block is packed. Bitcoin Core used to not propagate OP_RETURN transactions larger than 83 bytes, but if such transactions exist in a new block, they will be recognized as valid by the nodes because they comply with consensus rules, and the chain will not fork.

After being on the chain, nodes can also take action, such as automatically discarding the data attached to OP_RETURN, thereby reducing their own storage overhead.

Possible impacts and suggestions

Front: May increase miner income, support Bitcoin ecosystem projects (such as Runes, Alkanes, and sidechains).

Negative: It causes congestion of block space for ordinary Bitcoin users.

Miners' attitudes are uncertain: on one hand, increased competition for block space may raise income; on the other hand, mining pools might not favor it, as the advantages of "exclusive services" for packing non-standard transactions will diminish.

Personal suggestion:

If the PR is approved but the user does not like it, they can choose to run a client with stricter restrictions (such as Bitcoin Knots) or an older version. Reassess the role of Bitcoin Core (weighing between security patches, node policies, and consensus rules), and consider selecting a client that aligns more closely with personal principles.

Reference link: