Bitcoin OP_RETURN controversial proposal: return to freedom or increase congestion?

Compiled by GaryMa Wu Talks about Blockchain

Recently, HashKey Investment Research Director @jeffrey_hu detailed the background and controversy of Bitcoin Core's proposal to "cancel OP_RETURN data restrictions". Wu said he summarized and integrated the views of relevant community members and compiled them as follows.

Background review: OP_RETURN data restriction controversy

OP_RETURN is an opcode in Bitcoin Script that is used to embed small amounts of data in Bitcoin transactions. It allows users to store data on the blockchain, but these outputs are "provably unspendable" and therefore do not add to the burden of the UTXO (unspent transaction output) set. The current default limit of Bitcoin Core is 80 bytes for OP_RETURN data size, and the propagation of OP_RETURN transactions larger than 83 bytes is restricted by node policy (not consensus rules).

Developer Peter Todd proposed PR #32359, suggesting removing this restriction and deleting related configuration options (such as -datacarrier and -datacarriersize) at the same time, which was equivalent to cutting off the node's hope of self-configuration, sparking heated discussions.

Viewpoints

Supporters’ views:

● Existing limits are ineffective as they can be circumvented by submitting directly to the miner mempool (e.g. MARA Slipstream) or unrestricted node implementations (e.g. the largest known OP_RETURN output is 79,870 bytes).

● Some users even use OP_RETURN to treat the chain as a message board. There are also tools to help package and upload to the chain (opreturnbot.com), as long as you pay a fee.

● Removing the limit may be more compatible with miner incentives, as miners can earn more revenue by competing for block space.

Opponents’ view:

● Removing restrictions will result in more non-transaction data being written to the chain (such as shitcoin), occupying block space and pushing 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 opinion collection:

Nothing Research partner @0x_Todd: Supports the removal of the 80-byte data limit for OP_RETURN. He believes that the current limit is ineffective and that removing the limit can bring many benefits, including returning to Bitcoin's early design, reducing network burden, supporting ecological development, increasing miners' income, and being in line with libertarian ideas.

1. Unrestricted in the Satoshi era, returning to the classics

● In the Satoshi Nakamoto era (early Bitcoin), OP_RETURN did not have any byte limit.

● In 2014, Bitcoin introduced a 40-byte limit (later raised 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 "heresy", but a return to the classical design of the Satoshi Nakamoto era, which is in line with the original spirit of Bitcoin.

2. Current restrictions are invalid and can be easily bypassed

● The current 80-byte limit is ineffective, like a "10-cm-high fence" that cannot prevent users from storing large data.

● Bypass methods include: using protocols such as Inscriptions and Runes to store data through multiple transactions.

● Bypass through node policies, such as using the Libre Relay client (whose slogan is "Eliminate paternalism in Bitcoin Core's relay policy"). Peter Todd (the proposer of PR #32359) is one of the core developers of Bitcoin Core, and his contribution ranks in the top ten. His support for removing restrictions is a manifestation of "de-paternalism" and deserves support.

3. Reduce the burden of inscriptions on the network

● Inscriptions currently store data through a "bug" method (for example, bypassing the 80-byte limit through multiple transactions), which increases the network burden.

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

● Additional note: Inscriptions are no longer popular, so this reason is just a "bonus" (secondary reason).

4. Providing additional income to miners is in line with liberalism

● Removing restrictions could generate additional revenue for miners.

● Example: 0x_Todd mentioned a 7MB “super large card bug” OP_RETURN block, the sender paid $3,600 in transaction fees.

● This shows the authenticity of market demand: someone is willing to pay for putting large-size data on the chain, and miners are willing to package it.

● 0x_Todd holds a liberal stance and believes that this kind of “market-determined” behavior (mutual consent) should not be restricted and that rigid intervention is meaningless.

● Additional benefits: As Bitcoin is halved every four years, miners’ income decreases. Allowing large-sized OP_RETURN transactions can increase income, incentivize miners to continue to invest computing power, and consolidate the security of the Bitcoin network.

HashKey Investment Research Director @jeffrey_hu: I tend to oppose the removal of the 80-byte data limit for OP_RETURN. He believes that removing the limit may have negative effects (such as non-transaction data occupying block space), while emphasizing the importance of user freedom (retaining configuration options). He believes that support and opposition are more of a difference in concepts, and there is no absolute right or wrong in the short term. In response to @0x_Todd's four arguments, he elaborated on his own views:

1. There were no restrictions in the Nakamoto era, but that does not mean it is reasonable

● There were no restrictions on OP_RETURN in the Satoshi Nakamoto era, but not all of Satoshi Nakamoto’s designs were reasonable, and many early designs were later proven to have problems (such as some modifications before and after the block war).

● We cannot simply support the removal of restrictions on the grounds that “there were no restrictions in the Satoshi Nakamoto era”. Satoshi Nakamoto’s designs may not all be applicable today.

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

● Lifting the restriction is only a proposal from the Bitcoin Core client, not a decision from the entire Bitcoin network.

● Peter Todd is a senior developer whose philosophy tends to be "incentive compatibility" (similar to the logic of Full-RBF: guard against gentlemen but not villains). His proposal to remove restrictions is in line with his style, but not surprising.

● Bitcoin Core’s “paternalistic” practices (e.g., removing configuration options) are worth discussing and may restrict user freedom.

3. Inscription issue: Removing restrictions has limited significance

● Removing the 80-byte limit has limited help for Inscriptions.

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

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

4. Miner income and liberalism: User freedom is more important

● The impact on miners’ income is complex (it may increase income, but it may also damage the “exclusive service” advantage of the mining pool).

● Support liberalism: users have the right to pay to be on-chain, and OP_RETURN to store data is more elegant than inscriptions (two transactions + adding UTXO dust).

● But emphasize user freedom: As a full node operator, he needs to be free to choose whether to disseminate this data (for example, the content of the message board has nothing to do with him).

● Criticized Bitcoin Core for removing configuration options (such as -datacarriersize and Full-RBF configuration), depriving users of choice.

● If Bitcoin Core does not provide this freedom, he may switch to Bitcoin Knots or add transaction filters, but believes that this approach may be "a futile effort."

@crypcipher, founder of UTXO Stack: Supports the removal of restrictions, and believes that it is better to open it directly than to allow people to bypass it. He mentioned that protocols such as ordi write more than 80 bytes of data through multiple transactions, and removing restrictions can reduce this "useless work" and UTXO dust.

Fiamma co-founder @cyimonio: I oppose this and think that some Bitcoin L2 projects (such as storing state data on Bitcoin) only use Bitcoin as a data availability (DA) layer, which is not very meaningful and is a case of “spending a lot of money to do small things.”

Consensus rules and node strategy

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

It is useful, but to understand this issue, we still have to start with OP_RETURN and the "consensus rules" and "node strategies" it involves.

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

The behavior of OP_RETURN ( terminating script execution and marking 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 do not care about the specific size of the accompanying data.

The specific size limit of the data attached to OP_RETURN belongs to the node strategy. Nodes can do a lot, because they can decide how to process the transaction data they receive.

● Before the block is uploaded to the blockchain: Before the block is packaged, there are restrictions on whether the transaction can be propagated in the P2P network. In the past, Bitcoin Core did not propagate OP_RETURN transactions larger than 83 bytes, but if such transactions exist in the new block, the nodes will recognize the transaction as valid and the chain will not fork because it complies with the consensus rules.

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

Possible impacts and suggestions

Positive : May increase miners’ income and support Bitcoin ecosystem projects (such as Runes, Alkanes, and side chains).

Negative : It squeezes the block space of ordinary Bitcoin users.

Miners’ attitude is uncertain : on the one hand, increased competition for block space may increase revenue; on the other hand, mining pools may not like it because the “exclusive service” advantage of non-standard transaction packaging will be reduced.

Personal advice :

If the PR passes but the user doesn't like it, they can choose to run a more restrictive client (such as Bitcoin Knots) or an older version. Re-examine the role of Bitcoin Core (balancing security patches, node strategies, and consensus rules) and consider choosing a client that is more in line with your personal philosophy.

Reference Links:

https://x.com/jeffrey_hu/status/1917491946609860991

https://x.com/0x_Todd/status/1917889200684454340

https://x.com/jeffrey_hu/status/1917970887917343184