Original translation: GaryMa, Wu Talks Blockchain
Recently, HashKey Investment Research Director @jeffrey_hu detailed the background and controversy of Bitcoin Cores 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), which also cut off the nodes hope of self-configuration, sparking heated discussions.
Viewpoints
Supporters’ views:
The existing limit is ineffective as it can be circumvented by submitting directly 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 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), taking up block space and pushing up transaction fees.
Although restrictions can be circumvented, node policies can still be 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 Bitcoins 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 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-centimeter-high fence that cannot prevent users from storing large data sizes.
Bypass methods include: using protocols such as Inscriptions and Runes to store data through multiple transactions.
Bypass through node policy, such as using the Libre Relay client (whose slogan is Eliminate paternalism in Bitcoin Cores 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. Supporting the removal of restrictions is a manifestation of de-paternalism and deserves support.
3. Reduce the burden of inscriptions on the network
Inscriptions currently store data through bugs (for example, bypassing the 80-byte limit through multiple transactions), which increases the network burden.
After removing the 80-byte limit, the inscription 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 to miners is in line with liberalism
Removing the restriction could generate additional revenue for miners.
For example: 0x_Todd mentioned a 7 MB super large card bug OP_RETURN block, the sender paid $3,600 in 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-size 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_Todds 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 use the reason that “there were no restrictions in the Satoshi Nakamoto era” to support the removal of restrictions. Satoshi Nakamoto’s designs may not all be applicable today.
2. Peter Todd’s stance and the role of Bitcoin Core
Lifting the limit is only a proposal from the Bitcoin Core client, not a decision for 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 Cores paternalistic practices (such as removing configuration options) are worth discussing and may limit user freedom.
3. Inscription issue: Removing restrictions has limited significance
Removing the 80 byte limit will only help Inscriptions to a limited extent.
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 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 libertarianism: users have the right to pay to be on-chain, and OP_RETURN data storage is more elegant than inscriptions (two transactions + increasing UTXO dust).
But it emphasizes 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).
Bitcoin Core has been criticized for removing configuration options (such as -datacarriersize and Full-RBF configuration), depriving users of choice.
If Bitcoin Core doesn’t offer that freedom, he might switch to Bitcoin Knots or add transaction filters, but believes that such an approach would 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 it. I think 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 is a node policy. Nodes can do a lot because they can decide how to process the transaction data they receive.
Before the transaction 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 costs.
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 doesnt 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
