Author: Huang Shiliang, Lightning HSL
Recently, the discussion about Op_Return output in BTC has been very intense, which sparked my curiosity, and I decided to write an article to summarize. Actually, this article is mainly written for myself to read, and unless you particularly care about protocols and technology, there's no need to waste time reading it.
Even now, with AI being so powerful, I think letting 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, which happened to be right 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 UTXO, and the potential relationship with inscriptions.
However, given my terrible price predictions, I didn't say anything, as I can't influence others' wealth. Moreover, I sincerely feel that technology and price are now completely disconnected.
Historically, the Core development group, as the "official" of Bitcoin, has been strictly guarding against stuffing various data unrelated to Bitcoin's monetary attributes onto the Bitcoin blockchain. This policy has been maintained from when Op_return was introduced to Bitcoin in 2014 until just before the recent joint statement by 31 Core contributors. Core has always maintained a minimalist stance towards "non-financial data": 1) Maximum of 1 OP_RETURN per transaction; 2) Single data cannot exceed 80 bytes; 3) Nodes can manually adjust with -datacarriersize, which essentially is not a consensus rule.
Core's official attitude and code practices have always been to strictly limit "non-financial" data on-chain.
However, recently the Bitcoin Core code repository updated its attitude towards these "non-financial" data, suddenly relaxing restrictions and taking a particularly large step.
Core developer Peter Todd (who now claims everywhere that he's not a Core contributor, but a researcher, ha) proposed a PR #32359 "Remove arbitrary limits on OP_RETURN outputs" in April 2025, suggesting: 1)
Delete the 80-byte and "single output" check; 2) Deprecate -datacarriersize related options; 3) Leave other DoS protection to market fees + bandwidth comprehensive judgment.
It needs to be noted that this PR has not yet been merged into the Bitcoin Core main code repository, but the recent joint statement by 31 developers essentially "endorses" the policy relaxation, and it looks like the PR will be merged.
Additionally, in May 2021, BCH's upgrade made similar rule updates, but this time BTC's rules are more radical. BCH still restricts the total byte size of op_return in a single transaction to not exceed 223 bytes, with multiple op_return outputs possible in a BCH transaction, but total bytes cannot exceed 223 bytes.
BTC's PR does not limit the total byte volume of Op_return in a single transaction, but BTC's single transaction has a 1M byte limit, so it can be considered that the byte limit for Op_return in a single transaction is 1M.
The above is the policy change in the code layer of Bitcoin Core node software regarding "non-financial data" on-chain.
Why was this change made?
Since inscriptions became popular in 2022, the total data volume of the Bitcoin blockchain (total file size nodes need to download) and UTXO count (data that must permanently reside in node software memory) have massively expanded.
Below is the historical data of Bitcoin blockchain data expansion after inscriptions became popular, which I researched using ChatGPT O3 model and drew.
Blockchain total data volume expanded from ≈ 430 GB (2022-10) to ≈ 665 GB (2025-06);
UTXO set once peaked at 188 million entries (2024-12), more than double that of 2022;
(OP_RETURN itself does not enter UTXO, but fragmented Taproot outputs will significantly raise this.)
Having Bitcoin's chain simultaneously "fat + fragmented" caused disk expansion of 60%, UTXO doubled, which made many developers worried about decentralization costs.
Since 2022, the Core development group has held extremely hostile attitudes towards inscription applications, strongly requesting further restrictions on these data at the rule level. The mainstream view of Core developers is that for Bitcoin blockchain to be decentralized, these non-financial data must be limited to prevent node operation costs from expanding.
Luke Jr represents this view, and his self-developed node software Knots directly restricts relaying transactions for inscription-type applications that stuff data into op_return, meaning Knote as a Bitcoin node software will not forward inscription transactions.
Op_return itself is prunable by node software in Bitcoin rules, meaning it lacks the typical blockchain capability of permanent data preservation.
Many other inscription applications, fearing data restrictions by Bitcoin rules, have used various hack methods to design protocols, evolving from using Op_return to stuffing data into Taproot scripts, storing in transaction witness data.
In witness data, benefiting from Segwit's fee discount and the 3M upper limit of witness data block, these inscription data became cheaper in miner fees, simpler to design compared to op_return, and protected by Bitcoin protocol, not subject to pruning.
This further infuriated many Core developers.
But except for a few Core developers, the entire ecosystem seems to welcome these inscription applications, including miners and exchanges, all openly supporting them.
Exchanges are listing various inscription tokens in large quantities.
Miners are even extensively packaging non-standard script transactions to accommodate larger and more complex transactions produced by many inscription protocols, which practically breaks Op_return data restrictions because essentially this restriction is not a consensus-layer restriction - as long as a mining pool packages it, other pools won't refuse.
The difference between the above two scenarios in their impact on Bitcoin blockchain data is significant. Both Op_return data and Taproot scripts will significantly increase block data volume and UTXO count. However, from a full node operation perspective, Op_return data is prunable, but Taproot scripts are not.
This situation has developed to a point of forcing protocol changes.
If inscription applications cannot be stopped, perhaps loosening Op_return data restrictions at the protocol layer and guiding them to use Op_return instead of Taproot scripts might be more node operation-friendly.
This caused two factions among Core developers, with a small number firmly believing that inscription-generated "garbage data" should be blocked at the protocol layer, steadfastly believing that inscription applications are a DDOS attack on Bitcoin.
More developers feel it's about choosing the lesser evil, guiding data towards op_return rather than spendable scripts.
This is the situation I currently see.
What result do I think will develop from the current situation?
Protocol-layer changes to Op_return data will not cause a Bitcoin chain split, as this is not a consensus-layer change. Moreover, the most extreme action taken by those strongly opposing "non-financial data" on-chain, like Luke Jr, is merely limiting node relay of inscription transactions, not directly defining them as illegal in the protocol.
So this controversy has no risk of splitting.
But I think Bitcoin Core node software will develop towards relaxing Op_return data restrictions. The Luke Jr faction is likely to accept it. From the articles I've read, Luke Jr is a determined fighter, extremely committed to his principles, but this time I think he'll either prepare for a long-term battle or accept it.
Inscription and Layer 2 applications might welcome a more friendly Bitcoin underlying protocol development environment.
But about the price, I truly have no idea.
