Bitcoin’s Recent Op_Return Discussion and Bitcoin Core Node Policy

Author: Huang Shiliang, Lightning HSL

Recently, Bitcoin’s discussion on Op_Return output has been very intense, and it has aroused my curiosity. I decided to write an article to summarize it. In fact, such articles are mainly written for yourself. Unless you are particularly concerned about the agreement and technology, there is no need for everyone to waste time reading them.

Even now that AI is so strong, I think it would be much better to write chatgpt o3 or gemini 2.5 pro deep research to you than I do.

A few days ago, a friend wanted to short Ordi, which happened to be the time after 31 Core contributors jointly issued the Transaction Forwarding Policy Statement.

I really want to tell him about these discussions about Op_Return and data to UTXO, as well as potential relationships with inscriptions.

But given that my price prediction is really bad, I still didn't say that it can't affect others' wealth. And I really feel that technology and price are completely separated now, and it doesn’t matter.

The Core development team, as the "official" of Bitcoin, has always been strictly guarded against all kinds of data that are not related to Bitcoin's currency attributes on the Bitcoin blockchain. This policy started with Op_return being introduced to Bitcoin in 2014 and continued until the recent joint statement of 31 Core contributors, and was strictly guarded. Core has always held a minimization position on "non-financial data": 1) Each transaction has a maximum of 1 OP_RETURN; 2) A single piece of data cannot exceed 80 bytes; 3) allows nodes to be manually increased with -datacarriersize, which means that this is not a consensus rule in essence.

Core's official attitude and code practice have always strictly restricted the on-chain "non-financial" data.

But recently, Bitcoin Core's code repository updated its attitude towards these "non-financial" data, suddenly relaxing restrictions on these data, and taking particularly big steps.

Core developer Peter Todd (this guy now claims that he is not a Core contributor, but a researcher, ha) will launch a PR #32359 in April 2025 "Remove arbitrary limits on OP_RETURN outputs", suggesting: 1)

Delete a single 80-byte and "single output" check; 2) Abandon the related options of datacarriersize; 3) The remaining DoS protection is subject to comprehensive judgment by market costs + bandwidth.

It should be noted that this PR has not been merged into the Bitcoin core main code repository, but the recent joint statement from 31 developers is equivalent to "endorsing" the relaxation policy, and it seems that this PR is to be merged.

In addition, the upgrade of BCH in May 2021 was a similar rule update, but this time the BTC rules are more radical. BCH still limits the total byte size of op_return for a single transaction at the code level. In a bch transaction, there can be multiple op_return outputs, but the total number of bytes cannot exceed 223 bytes.

This time, BTC's PR did not limit the total bytes of Op_return in a single transaction, but Bitcoin's single transaction has a limit of 1M bytes, so it can also be considered that the byte limit of Op_return in a single transaction is 1M.

The above is the policy change of Bitcoin Core node software to "non-financial data" on the code level.

Why is this change?

Since the inscription became popular in 2022, the total data volume of Bitcoin blockchain (the total number of files that node software needs to download) and the number of UTXO (the data that must be resident in memory in the node software) have expanded on a large scale.

Below is the history of the expansion of Bitcoin blockchain data after I used the chatgpt o3 model to investigate the data and drew the inscription.

The total amount of blockchain data expanded from ≈ 430 GB (2022-10) to ≈ 665 GB (2025-06);

The UTXO collection once reached 188 million (2024-12), more than twice that in 2022;

(OP_RETURN itself does not enter UTXO, but the fragmented Taproot output will be significantly higher.)

The "fat body + multiple fragments" on the Bitcoin chain appear at the same time, the disk swells by 60%, and the UTXO is twice, which makes many developers worry about the cost of decentralization.

Since 2022, the Core development team has been very hostile to the application of inscriptions and other inscriptions, and strongly demands that these data be further restricted at the rule level. The mainstream view of Core developers is that if the Bitcoin blockchain is to be decentralized, it must limit these non-financial data so that the node operation cost will not inflate.

Here, Lukejr is represented by Lukejr. The node software Knots developed by Lukejr directly restricts the relay of transactions for inscription applications that stuff data into op_return. That is, Knote, as a Bitcoin node software, does not forward it after receiving the inscription transaction.

Op_return itself can be cut by node software in Bitcoin rules, which means it does not have the ability to permanently save data common to blockchain.

Many other inscription applications are worried that their data is restricted by Bitcoin rules, so they use various hack methods to design protocols, from using Op_return to stuffing data into taproot scripts and saving them in transaction witness data (witness).

In the witness data, benefiting from the discounted handling fee of segwit and the 3M upper limit of witness data blocks, the miner fee for these inscription data is cheaper, it is simpler to design than op_return, and is protected by the Bitcoin protocol and will not be cut.

This has made many developers in the Core development team even more popular.

But except for a small number of Core developers, it seems that the entire ecosystem is very popular with these inscription applications, including miners and exchanges, which are all supported by Ming Cards.

A large number of inscription tokens are listed on the shelves.

Miners even package non-standard script transactions in large quantities to cooperate with the larger and more complex transactions generated by many inscription protocols. This actually breaks through the limitation of op_return data, because in essence this limitation is not a consensus-level restriction. As long as there is a mining pool package, other mining pools will not refuse.

The above two situations have a great difference in the impact of Bitcoin blockchain data. Op_return class data and taproot scripts will significantly increase the amount of block data and will also increase the number of UTXOs. However, from the perspective of full node operation, Op_return data is cutable, but taproot scripts are not cutable.

Such a situation is about to force the agreement to change.

If the inscription application cannot be blocked, then at the protocol level, if the restrictions on Op_return data are relaxed, the inscription application will be relaxed, and the guidance will be more friendly to Bitcoin node operations, and the node operation will be carried out.

This has caused two factions to be created by Core developers. A small amount of firmly believes that the "scrap data" generated by inscription applications should be blocked at the protocol layer. They firmly believe that inscription applications are DDOS launched against Bitcoin.

More developers think that the two rights are less important, and guide the data to op_return rather than spendable scripts.

That's what I'm seeing right now.

What will I think will result if the current situation continues to develop?

Changes to the protocol layer of Op_return data will not cause a split in the Bitcoin chain, which is non-consensus layer. Moreover, the most extreme approach taken by parties like Luke jr who strongly oppose "non-financial data" is simply to restrict the node's relay of inscription transactions, rather than to directly set it as illegal in the agreement.

So this time the controversy has no risk of division at all.

But I think the Bitcoin core node software will move towards relaxing Op_return data restrictions. Luke jr probably wants to recognize this faction. According to the article I have read, Luke jr is a firm fighter and is extremely firm in his own ideas. But this time I think Luke jr either prepares for a long-term battle or recognizes it.

Inscriptions and layer two applications may usher in a more friendly Bitcoin underlying protocol development environment.

But I really don't know the price.