Recent discussions on Op_Return in Bitcoin and Bitcoin Core node policy

Author: Huang Shiliang, Lightning HSL

Recently, the discussion about Bitcoin's Op_Return outputs has been very intense, which sparked my curiosity, and I decided to write an article summarizing it. In fact, such articles are mainly written for myself; unless one is particularly concerned about the protocol and technology, there is no need for others to waste time reading it.

Even now, with AI being so powerful, I think having ChatGPT O3 or Gemini 2.5 Pro Deep Research write for everyone would be much better than what I could write.

A few days ago, a friend wanted to short Ordi, just after 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 stuffing data into UTXOs, as well as the potential relationship with inscriptions.

However, given that my predictions about prices have been terrible, I refrained from saying anything; I can't affect others' ability to make money. Moreover, I sincerely feel that technology and price are now completely disconnected and have nothing to do with each other.

All along, the Core development team, as the "official" entity of Bitcoin, has been very strict about preventing various data unrelated to Bitcoin's monetary attributes from being stuffed into the Bitcoin blockchain. This policy has been in place since OpReturn was introduced to Bitcoin in 2014 and has continued until the recent joint statement by the 31 Core contributors, which has been a solid defense. The Core has always maintained a minimal stance 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 coding practices of Core have always strictly limited the on-chain presence of "non-financial" data.

However, recently, the Bitcoin Core code repository updated its attitude towards these "non-financial" data, suddenly relaxing the restrictions on this data and making significant strides.

Core developer Peter Todd (who now claims everywhere that he is no longer a Core contributor, just a researcher, haha) proposed a PR #32359 "Remove arbitrary limits on OP_RETURN outputs" in April 2025, suggesting: 1) removing the single 80-byte and "single output" checks; 2) discarding -datacarriersize related options; 3) leaving the remaining DoS protection to market fees + bandwidth comprehensive judgment.

It should be noted that this PR has not yet been merged into the Bitcoin Core main code repository, but the recent joint statement by the 31 developers effectively endorses the relaxation policy, indicating that this PR is likely to be merged.

Additionally, in May 2021, BCH's upgrade made 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. In a BCH transaction, there can be multiple opreturn outputs, but the total byte size cannot exceed 223 bytes.

In contrast, BTC's PR does not impose any 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 is the change in policy regarding the on-chain presence of "non-financial data" at the code level in the Bitcoin Core node software.

Why has this change occurred?

Since inscriptions gained popularity in 2022, the total data volume of 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 the historical data on the inflation of Bitcoin blockchain data after inscriptions gained popularity, which I researched using the ChatGPT O3 model and illustrated.

The total data volume of the blockchain has expanded from ≈ 430 GB (October 2022) to ≈ 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 will significantly increase the count.)

The simultaneous emergence of "fat body + more fragments" on the Bitcoin chain, with disk usage swelling by 60% and UTXOs doubling, has raised concerns among many developers about the cost of decentralization.

Since 2022, the Core development team has held a very hostile attitude towards the applications of inscriptions, strongly demanding 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 restricted to prevent the operating costs of nodes from inflating.

Lukejr represents this view; his own developed node software, Knots, directly restricts the relaying of transactions that involve stuffing 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 blockchain data to be permanently stored.

Many other inscription-type applications are concerned about their data being restricted by Bitcoin rules and have used various hack methods to design protocols, evolving from utilizing Op_return to stuffing data into Taproot scripts and storing it in the transaction's witness data.

In the witness data, benefiting from SegWit’s fee discounts and the 3M limit on witness data blocks, the miner fees for these inscription-type data are cheaper, and designing them is simpler than Op_return, while being protected by Bitcoin protocol, thus not subject to pruning.

This has further angered many developers in the Core development team.

However, aside from a few Core developers, it seems the entire ecosystem welcomes these inscription-type applications, including miners and exchanges, who openly support them.

A large number of transactions involving various inscription-type tokens are being listed.

Miners are even packaging a large number of non-standard script transactions to accommodate the larger and more complex transactions generated by many inscription-type protocols, which effectively breaks through the limitations on op_return data, as this limitation is not fundamentally a consensus-level restriction; as long as there are mining pools packaging them, other mining pools will not refuse.

The impact of the above two situations on Bitcoin blockchain data is significantly different. Opreturn-type data and Taproot scripts will both significantly increase the block data volume and the number of UTXOs. However, from the perspective of running a full node, Opreturn data is prunable, while Taproot scripts are not.

This development of the situation has reached a point where it may force a change in the protocol.

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 the emergence of two factions among Core developers: a small number firmly believe 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, more developers feel that it is better to guide data towards Op_return rather than spendable scripts, choosing the lesser of two evils.

This is the situation as I see it currently.

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 level issue. Moreover, the most extreme measures taken by those like Lukejr, who strongly oppose the on-chain presence of "non-financial data," are merely to restrict nodes from relaying inscription-type transactions, rather than directly establishing them as illegal in the protocol.

Therefore, this controversy poses no risk of a split.

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 warrior, extremely firm in his beliefs, but this time I think he either needs to prepare for a long battle or accept the situation.

Inscriptions and second-layer applications may welcome a more friendly development environment for Bitcoin's underlying protocol.

But as for the price, I truly have no idea.