Recently, a proposal to remove the size limit on additional data carried by OP_RETURN in the Bitcoin Core client has caused a stir in the industry. A typical proponent is developer Peter Todd, who has repeatedly submitted PRs (Pull Requests), showing a determination to not give up until the goal is achieved.
On July 23, 2023, Peter Todd submitted PR#28130, proposing to remove the restrictions on OP_RETURN carrying data. The PR was closed and not adopted.
On April 28, 2025, he was not discouraged and submitted the same content proposal PR#32359 again, aggressively demanding not only the removal of additional data limits but also the deletion of configuration options to prevent client software users from independently using options to lift the restrictions.
The proposal received opposition from the majority.
Another developer, instagibbs, proposed a slightly more moderate proposal PR#32406. He suggested temporarily retaining the configuration options but not imposing restrictions by default.
This proposal has also garnered a lot of support. Instagibbs even wrote an explanation for it, detailing the origins of OP_RETURN and why such a change is proposed.
A typical opponent is developer Luke Dashjr. He is the maintainer of the Bitcoin Knots client software and vehemently opposed inscriptions two years ago. Specifics can be reviewed in previous articles from the teaching chain.
For the average reader, to simply understand this issue, the teaching chain can make this analogy:
Remove additional data limits + virtual machine executing additional data = Ethereum
Of course, it is not that simple. The Bitcoin ledger uses a stateless UTXO model, and to modify the ledger to store state data (which brings new problems like state explosion) would be closer to Ethereum's design.
In any case, it was precisely because Bitcoin Core refused Vitalik Buterin's request to use the additional data capabilities of the Bitcoin ledger to implement the smart contract he envisioned that he was forced to establish Ethereum.
And in this cycle so far, those who bet on Ethereum outperforming BTC must have quite a few prairie animals rushing past in their minds.
Since this capability is just a feature 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 that of 2017.
The main reasons for support include: many modified clients have already removed this restriction and received support from certain mining pools; it may provide more incentives for miners; the ability to restrict OP_RETURN cannot stop people from cleverly using other capabilities such as multisig or taproot scripts to carry data, but rather the restrictions may inadvertently lead to fragmentation of UTXOs due to data splitting and stitching; it is better to be lenient rather than strict, as there is no one-size-fits-all method to accurately identify what constitutes junk data, which is destined to be a futile cat-and-mouse game; and so on.
The main reasons for opposition include: relaxing data restrictions could rapidly inflate the Bitcoin ledger, thereby weakening decentralization; it could bring a large number of non-financial applications, diluting BTC's positioning and reducing it to a mere checkbook; and so on.
According to statistics from Clark Moddy Bitcoin, the current size of the Bitcoin blockchain is approximately 748.1GB, of which OP_RETURN additional data is about 3.83GB, accounting for approximately 0.5%.
There is currently no definitive conclusion on whether the relevant PR will be merged and released. However, based on the community's voting results, the number of nodes using the slimmed-down version of Bitcoin Knots has now exceeded the number of nodes running the latest version Bitcoin Core 29.0.
Perhaps we will witness a historic moment: Bitcoin, as a consensus, does not necessarily have to rely on a single dominant client software. (Although this is already a fact, it is just that many people are not aware of it.)
A diversified Bitcoin ecosystem, with two to three equally matched Bitcoin client software, codebases, and development and maintenance teams competing against each other, following a set of Bitcoin consensus, harmonious yet different, fighting yet not breaking, might instead highlight the charm of Bitcoin's decentralization.
