Written by: Liu Jiaochain
Recently, a proposal to remove the data size limit for OP_RETURN in the Bitcoin Core client has caused a stir in the industry. Typical promoters like developer Peter Todd have repeatedly submitted PRs (Pull Requests), seemingly determined to achieve their goal.
On July 23, 2023, Peter Todd submitted PR#28130, proposing to remove the data limit for OP_RETURN. The PR was closed and not adopted.
On April 28, 2025, he persisted and submitted another identical proposal, PR#32359. He radically demanded not only removing the additional data limit but also deleting the configuration options to prevent client software users from manually lifting the restrictions.
The proposal was opposed by most people.
Another developer, instagibbs, proposed a slightly milder PR#32406. He suggested temporarily retaining the configuration options but defaulting to no restrictions.
This proposal also received mixed reactions. instagibbs wrote an explanation about the origin of OP_RETURN and the reasons for the proposed changes.
A typical opponent is developer Luke Dashjr, the maintainer of the Bitcoin Knots client software and someone who strongly opposed inscriptions two years ago. Readers can refer to previous articles by Jiaochain for more details.
For ordinary readers, Jiaochain can provide a simple analogy:
Removing additional data limit + Virtual machine executing additional data = Ethereum
Of course, it's not that simple. Bitcoin's ledger is a stateless UTXO model, and modifying the ledger to store state data (which would bring the problem of state explosion) would be closer to Ethereum's design.
In any case, it was Bitcoin Core's refusal to allow Vitalik Buterin to use the additional data capability of the Bitcoin ledger to implement his vision of smart contracts that forced him to create the Ethereum project.
In this cycle, those who bet on Ethereum outperforming BTC must have many grassland animals galloping through their minds.
Since this capability is just a feature of the client software and not part of the Bitcoin protocol consensus, there's no need to worry that this controversy will lead to a hard fork like in 2017.
Supporting reasons include: Many modified clients have already removed this limit and gained support from some mining pools; it might provide more incentives for miners; restricting OP_RETURN's capabilities won't prevent people from cleverly using other methods like multisig or taproot script to carry data, and the restrictions might actually lead to data fragmentation of UTXOs; it's impossible to precisely identify "garbage data"; and so on.
Opposing reasons include: Removing data restrictions could cause the Bitcoin ledger to expand rapidly, weakening decentralization; it could bring in many non-financial applications, diluting BTC's positioning and reducing it to a checkbook; and so on.
According to Clark Moddy Bitcoin's statistics, the current Bitcoin blockchain size is about 748.1GB, with OP_RETURN additional data accounting for approximately 3.83GB, or about 0.5%.
There's no definitive conclusion yet on whether the related PRs will be merged and released. However, based on the community's "voting with their feet," the number of nodes using the slim version Bitcoin Knots now exceeds the latest Bitcoin Core 29.0 version.
We may witness a historic moment: Bitcoin, as a consensus, does not necessarily depend on a single dominant client software. (Although this has always been a fact, just not recognized by many)
Wouldn't a diverse Bitcoin ecosystem with two to three equally competitive client software, code libraries, and development teams competing with each other, following a Bitcoin consensus, be different but united, competing but not breaking, better demonstrate the charm of Bitcoin's decentralization?
