Written by: @jeffrey_hu Compiled by: GaryMa, Wu said blockchain
Recently, HashKey Investment Research Director @jeffrey_hu has detailed the background and controversy of the Bitcoin Core proposal to "cancel the OP_RETURN data limit". Wu said that he has summarized and integrated the views of relevant people in the community and compiled them as follows.
Background review: OP_RETURN data limit 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 increase the burden on the UTXO (unspent transaction output) set. The current default limit of Bitcoin Core is 80 bytes for OP_RETURN data, and node policies (not consensus rules) are used to restrict the propagation of OP_RETURN transactions larger than 83 bytes.
Developer Peter Todd proposed PR #32359, suggesting the removal of this limit and the removal of related configuration options (such as -datacarrier and -datacarriersize), which also cut off the node's hope of self-configuration, sparking heated discussions.
Viewpoints
Supporters' views:
The existing limit is invalid because it can be bypassed by directly submitting to the miner mempool (such as MARA Slipstream) or unrestricted node implementations (such as Libre Relay). (For example, 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 restrictions may be more compatible with miner incentives, because miners can earn more income by competing for block space.
Opposition point of view:
Removing restrictions will cause more non-transaction data to be written to the chain (such as shitcoin), squeezing block space and pushing up transaction fees.
Although restrictions can be bypassed, node strategies are still useful (for example, limiting propagation and reducing the pressure of junk data on the network).
Personal detailed opinions:
Nothing Research partner @0x_Todd: Support the removal of the 80-byte data limit for OP_RETURN, believing that the current limit is invalid and that removing the limit can bring many benefits, including returning to the early design of Bitcoin, reducing network burden, supporting ecological development, increasing miners' income, and conforming to the concept of libertarianism.
1. No limit in the Satoshi era, return to the classic
In the Satoshi era (early Bitcoin), OP_RETURN had no byte limit.
In 2014, Bitcoin introduced a 40-byte limit (later raised to 80 bytes) to maintain 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 era, which is in line with the original spirit of Bitcoin.
2. The current limit is invalid and can be easily bypassed
The current 80-byte limit is in name only, like a "10-centimeter-high fence wall", which cannot prevent users from storing large-size data.
Bypass methods include: using protocols such as Inscriptions and Runes to store data through multiple transactions.
Bypass through node strategies, 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 the restriction is a manifestation of "de-paternalism" and deserves support.
3. Reduce the burden of inscriptions on the network
Inscriptions currently store data in a "bug-like" way (for example, bypassing the 80-byte limit through multiple transactions), which increases the burden on the network.
After removing the 80-byte limit, inscriptions can directly store data through OP_RETURN, reducing unnecessary multiple transactions and reducing the pressure on the network.
Additional note: Inscriptions are no longer popular, so this reason is just a "bonus" (secondary reason).
4. Providing additional income for miners is in line with liberalism
Removing restrictions can bring additional income to miners.
For example: 0x_Todd mentioned a 7MB "super card bug" OP_RETURN block, the sender paid a handling fee of 3,600 US dollars.
This shows the authenticity of market demand: someone is willing to pay for large-size data to be on the chain, and miners are willing to package it.
0x_Todd adheres to the liberal position and believes that this "market-determined" behavior (you and I are willing) should not be restricted, and rigid intervention is meaningless.
Additional benefits: With the halving of Bitcoin every four years, miners' income has decreased. Allowing large-size OP_RETURN transactions can increase income, incentivize miners to continue to invest in computing power, and consolidate the security of the Bitcoin network.
HashKey Investment Research Director @jeffrey_hu: Tends 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 Satoshi era, but it does not mean it is reasonable
There were no restrictions on OP_RETURN in the Satoshi era, but not all of Satoshi's designs were reasonable. Many early designs were later proven to have problems (such as some modifications before and after the block war).
We cannot simply use "no restrictions in the Satoshi era" as a reason to support the removal of restrictions. Satoshi's designs may not be applicable today.
2. Peter Todd's position and the role of Bitcoin Core
Removing restrictions is only a proposal from the Bitcoin Core client, not a decision made by 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). It is in line with his style to propose the removal of restrictions, but it is not surprising.
Bitcoin Core's "paternalistic" approach (such as removing configuration options) is worth discussing and may restrict user freedom.
3. Inscription problem: Removing restrictions has limited significance
Removing the 80-byte limit will have 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 currency issuance).
Even if Bitcoin provides powerful functions (such as one-time seals, SegWit), there will always be people who will 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 miner 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 the chain, and OP_RETURN storage data is more elegant than inscriptions (two transactions + increase UTXO dust).
But emphasize user freedom: as a full node operator, he needs to freely choose whether to spread 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".
UTXO Stack founder @crypcipher: Supports the removal of restrictions, and believes that it is better to open it directly than to allow people to bypass it. It is mentioned that protocols such as ordi write more than 80 bytes of data through multiple transactions. Removing restrictions can reduce this "useless work" and UTXO dust.
Fiamma Co-founder @cyimonio: Oppose, believing 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 "spending a lot of money to do small things."
Consensus rules and node strategies
"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, whose function is to immediately terminate the execution of the script and mark the output as "provably unspendable".
OP_RETURN behavior (terminating script execution and marking 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 the specific size of the accompanying data.
The restriction on the specific size of the accompanying data of OP_RETURN belongs to the node policy. Nodes can do a lot because they can decide how to handle the transaction data they get.
Before chaining: Before the block is packaged, whether the transaction can be propagated in the P2P network is restricted. Bitcoin Core used to not propagate OP_RETURN transactions larger than 83 bytes, but if such transactions exist in the new block, because they meet the consensus rules, the node will also recognize the transaction as valid and the chain will not fork.
After being on-chain, nodes can also make a difference, such as automatically discarding the data attached to OP_RETURN to reduce their own storage costs.
Possible impacts and suggestions
Positive: It may increase miners' income and support Bitcoin ecological projects (such as Runes, Alkanes and side chains).
Negative: It will squeeze the block space of ordinary Bitcoin users.
Miners' attitude is uncertain: On the one hand, the increased competition for block space may increase income; on the other hand, mining pools may not like it because the "exclusive service" advantage of non-standard transaction packaging will be reduced.
Personal suggestion:
If the PR passes but the user does not like it, you 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 better fits your personal philosophy.
Catherine
Weatherly
Kikyo
Joy