This controversy poses no risk of division at all.
Written by: Huang Shiliang
Recently, there has been intense discussion about Op_Return outputs in Bitcoin, which has sparked my curiosity, prompting me to write an article summarizing the situation. In fact, this article is mainly for my own reference; unless one is particularly concerned about the protocol and technology, there's no need to waste time reading it.
Even now, with AI being so advanced, I believe having ChatGPT O3 or Gemini 2.5 Pro conduct deep research and write this would be far better than what I could produce.
A few days ago, a friend of mine wanted to short Ordi, coinciding with the time when 31 Core contributors jointly released the "Transaction Forwarding Policy Statement."
I really wanted to tell him about the discussions regarding Op_Return and the insertion of data into UTXOs, as well as the potential relationship with inscriptions.
However, given that my predictions about prices have been notoriously poor, I refrained from saying anything, as I wouldn't want to affect someone else's financial success. Moreover, I genuinely feel that technology and price are now completely disconnected and have no relation to each other.
Historically, the Core development team, as the "official" entity of Bitcoin, has been very strict about preventing various non-financial data from being inserted into the Bitcoin blockchain. This policy has been in place since the introduction of OpReturn in Bitcoin in 2014 and continued until the recent joint statement by the 31 Core contributors, which has been a firm stance against such practices. Core has maintained a minimalistic position on "non-financial data": 1) a maximum of 1 OPRETURN per transaction; 2) a single data entry cannot exceed 80 bytes; 3) nodes are allowed to manually increase the -datacarriersize, which essentially is not a consensus rule.
The official stance and code practices of Core have always been to strictly limit the on-chain presence of "non-financial" data.
However, recently, the Bitcoin Core code repository updated its stance on these "non-financial" data, significantly relaxing the restrictions on such data.
Core developer Peter Todd (who now claims he is no longer a Core contributor but just a researcher, haha) proposed PR #32359 "Remove arbitrary limits on OP_RETURN outputs" in April 2025, suggesting: 1) removing the 80-byte limit and "single output" check; 2) discarding options related to -datacarriersize; 3) leaving other DoS protections to be judged by market fees + bandwidth.
It should be noted that this PR has not yet been merged into the main Bitcoin Core code repository, but the recent joint statement by the 31 developers effectively endorses the relaxation of the policy, indicating that this PR is likely to be merged.
Additionally, in May 2021, BCH underwent a similar rule update, but this time BTC's rules are more aggressive. BCH still limits the total byte size of OPRETURN in a single transaction to 223 bytes, allowing multiple OPRETURN outputs in a BCH transaction, but the total byte count cannot exceed 223 bytes.
In contrast, BTC's PR does not impose a limit on the total byte size of OpReturn in a single transaction, but since Bitcoin has a 1M byte limit for a single transaction, it can also be considered that the byte limit for OpReturn in a single transaction is 1M.
This summarizes the recent policy change in the Bitcoin Core node software regarding the on-chain presence of "non-financial data."
Why has this change occurred?
Since inscriptions gained popularity in 2022, the total data volume on the Bitcoin blockchain (the total amount of files that node software needs to download) and the number of UTXOs (data that must reside in memory within the node software) have both expanded significantly.
Below is a historical chart I created using the ChatGPT O3 model, illustrating the data inflation of the Bitcoin blockchain after inscriptions became popular.
The total data volume of the blockchain has expanded from approximately 430 GB (October 2022) to approximately 665 GB (June 2025);
The UTXO set once surged to 188 million entries (December 2024), more than double that of 2022;
(OP_RETURN itself does not enter UTXO, but fragmented Taproot outputs significantly increase the count.)
The simultaneous emergence of a "bulky + fragmented" Bitcoin chain, with a 60% increase in disk space and a doubling of UTXOs, has raised concerns among many developers about the cost of decentralization.
Since 2022, the Core development team has held a very hostile stance towards the applications of inscriptions, strongly advocating for further restrictions on this data at the rule level. The mainstream view among Core developers is that to maintain decentralization in the Bitcoin blockchain, these non-financial data must be limited to prevent the operational costs of nodes from inflating.
Lukejr represents this viewpoint; his own developed node software, Knots, directly restricts the relaying of transactions that insert data into OP_RETURN for inscription-type applications, meaning that Knots does not forward inscription transactions upon receipt.
OP_RETURN itself can be pruned by node software according to Bitcoin rules, meaning it does not possess the common capability of permanent data storage on the blockchain.
Many other inscription-type applications are concerned about their data being restricted by Bitcoin rules, leading them to employ various hacks to design protocols, evolving from utilizing OP_RETURN to inserting data into Taproot scripts and storing it in the transaction's witness data.
In witness data, benefiting from SegWit’s fee discounts and the 3M limit on witness data blocks, the miner fees for these inscription-type data become cheaper, and the design is simpler than OP_RETURN, while also being protected by Bitcoin protocol, thus not subject to pruning.
This has further incited many developers within the Core development team.
However, aside from a few Core developers, the entire ecosystem seems to welcome these inscription-type applications, including miners and exchanges, who openly support them.
A large number of transactions featuring various inscription-type tokens have been listed.
Miners have even begun to package non-standard script transactions extensively to accommodate the larger and more complex transactions generated by many inscription-type protocols, effectively bypassing the OP_RETURN data limitations, as this limitation is not fundamentally a consensus-level restriction; as long as a mining pool packages it, other pools will not reject it.
The impact of the above two scenarios on Bitcoin blockchain data is significantly different. OPRETURN-type data and Taproot scripts both significantly increase the block data volume and the number of UTXOs. However, from the perspective of operating a full node, OPRETURN data is prunable, while Taproot scripts are not.
This development of the situation has reached a point where it is compelling a protocol change.
If inscription-type applications cannot be blocked, then relaxing the restrictions on OPRETURN data at the protocol level to guide these applications to use OPRETURN instead of Taproot scripts may be more friendly for the operation of Bitcoin nodes.
This has led to a division among Core developers, with a small faction firmly believing that the protocol should block the "garbage data" generated by inscription-type applications, firmly asserting that these applications are a DDoS attack on Bitcoin.
Meanwhile, a larger group of developers feels that a balance must be struck, guiding data towards OP_RETURN rather than spendable scripts.
This is the current situation as I see it.
What do I think will happen as the situation develops?
Changes to the protocol regarding OP_RETURN data will not lead to a split in the Bitcoin chain, as this is a non-consensus issue. Moreover, the most extreme measures taken by those like Lukejr, who strongly oppose the on-chain presence of "non-financial data," have only involved restricting nodes from relaying inscription-type transactions, rather than directly establishing them as illegal within the protocol.
Therefore, this controversy poses no risk of division at all.
However, I believe that the Bitcoin Core node software will move towards relaxing the restrictions on OP_RETURN data. The Lukejr faction will likely have to accept this; from what I have read, Lukejr is a staunch fighter, extremely committed to his beliefs, but this time I think he will either need to prepare for a long battle or concede.
Inscriptions and layer-two applications may welcome a more friendly development environment for Bitcoin's underlying protocol.
But as for the price, I truly have no idea.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
