OP_RETURN: One of the most serious BTC controversies

Overnight and this morning, the Federal Reserve's May interest rate meeting ended. After a short-term decline, BTC quickly rebounded and attacked, aiming at the resistance level of 99k.

Recently, a proposal to remove the size limit of additional data carried by OP_RETURN in the Bitcoin Core client has caused an uproar in the industry. Typical promoters such as developer Peter Todd have repeatedly submitted PR (Pull Request), which seems to mean that he will not give up until he achieves his goal.

On July 23, 2023, Peter Todd submitted PR#28130, proposing to remove the limit on the data carried by OP_RETURN. PR was closed and not adopted.

On April 28, 2025, he did not give up and submitted the same proposal PR#32359 again. He radically requested not only to remove the additional data restrictions, but also to delete the configuration options to prevent client software users from using options to open restrictions.

The proposal was opposed by the majority.

Another developer, instagibbs, proposed another slightly milder proposal PR#32406. He proposed to temporarily retain the configuration option, but not restrict it by default.

This proposal is also more likes than dislikes. instagibbs also wrote a note to explain the origin of OP_RETURN and why such a change was proposed.

Typical opponents include developer Luke Dashjr. He is the maintainer of the Bitcoin Knots client software and was also a fierce opponent of the inscription two years ago. For details, you can review the previous articles of the teaching chain.

For ordinary readers, to simply understand this issue, the teaching chain can make such a metaphor:

Removing the restriction on additional data + virtual machine execution of additional data = Ethereum

Of course, it is not that simple in reality. Bitcoin's ledger is a stateless UTXO model. Only by transforming the ledger to store state data (which will bring about a new problem, namely state explosion) can it be close to the design of Ethereum.

In any case, it was because Bitcoin Core refused Vitalik Buterin to use the additional data capabilities of the Bitcoin ledger to implement the smart contracts in his mind that he was forced to set up a new company to create the Ethereum project.

So far in this cycle, those who bet on Ethereum to outperform BTC must have had many grassland animals roaring and running through their hearts.

Since this capability is only a function of the client software, and not part of the Bitcoin protocol consensus, there is no need to worry that this dispute will lead to a hard fork like the one in 2017.

The main reasons for support include: many modified clients have already cancelled this restriction and have received support from some mining pools; it may bring more incentives to miners; limiting the ability of OP_RETURN cannot stop people from cleverly using other capabilities such as multisig and taproot script to carry data. On the contrary, the restrictions force people to split and splice data, resulting in the fragmentation of UTXO; it is better to unblock than to block, and there is no one-size-fits-all method to accurately identify what is junk data. This is destined to be a futile cat-and-mouse game; etc.

The main reasons for opposition include: relaxing data restrictions may cause the Bitcoin ledger to expand rapidly, thereby weakening decentralization; bringing a large number of non-financial applications, weakening the positioning of BTC, and reducing it to a checkbook; etc.

According to Clark Moddy Bitcoin, the current size of the Bitcoin blockchain is about 748.1GB, of which OP_RETURN additional data is about 3.83GB, accounting for about 0.5%.

There is no definite conclusion that the relevant PR will be merged and released. However, judging from the results of the community voting with their feet, the number of nodes using the slimmed-down version of Bitcoin Knots has exceeded the number of nodes in the latest version of Bitcoin Core 29.0.

Perhaps we will witness a historic moment: Bitcoin, as a consensus, does not necessarily rely on a single dominant client software. (Although this is a fact, it is just not realized by many people)

A diversified Bitcoin ecosystem with two or three equally powerful Bitcoin client software, code bases, and development and maintenance teams competing with each other, following a set of Bitcoin consensus, being harmonious but different, fighting but not breaking, can it better highlight the charm of Bitcoin decentralization?