In recent days, there has been much discussion on the open internet about a proposal to remove the OP_RETURN limit—an initiative put forward by Bitcoin Core OG developer Peter Todd.

(It is worth noting that in the HBO heavily promoted documentary "Banking on Bitcoin," Peter Todd was identified as Satoshi Nakamoto, leading to numerous funding requests and threats, causing him to currently live in seclusion.)

Although there has been considerable skepticism in the community regarding this OP_RETURN change, according to Bitcoin developer and Blockstream core contributor Greg Sanders (aka 'instagibbs') in a GitHub announcement on May 5th: in the next network upgrade, Bitcoin Core will no longer impose any byte or quantity restrictions on OP_RETURN.

What Exactly is OP_RETURN?

We all know that Bitcoin is an immutable ledger, where each transaction is like writing a record on it.

OP_RETURN is like sticking a "note" on the edge of a page—you can write several words of text or a small piece of data into it, and this note is marked by the system as "read-only," meaning others cannot use it as money or affect the records of other "money" on the ledger.

The reason for having this "note" function is that sometimes people want to permanently pin some additional information (such as legal proof, short messages, anniversaries, or even declarations of love) on the chain but do not want to occupy the space in the UTXO set used to store "spendable" bitcoins. With OP_RETURN, this information is treated like scrap paper thrown into a drawer—nodes only keep a trace, it does not occupy capacity, and the "available money" on the chain remains clean.

In the past, to prevent someone from writing a lengthy "note" that could clog the network, Bitcoin Core by default only allowed one OP_RETURN per transaction, limited to a maximum of 80 bytes of content. If exceeded, nodes would outright reject relaying and refuse to help in packaging.

Now, the 80-byte, single-item limit is completely gone—you can write as much as you want, as many notes as you like, and nodes will automatically relay, miners are happy to include.

However, in fact, there have always been people bypassing the 80-byte limit.

Even when there was an OP_RETURN limit, there were ways to bypass the 80-byte limit. No matter how strict the filtering and relay strategy was, it couldn't stop those who really wanted to write data on Bitcoin. Because only miners and fees decide which transactions get added to the chain, by offering higher rewards to miners, they naturally tend to include more transactions, and the gameplay will not change due to node policies.

For example, as many of you may know, Taproot Wizz, the great wizard of NFT, packed nearly a 4M image into a block, and in the past, Ordinals inscriptions, runes, and more used various "detours and workarounds" to bypass restrictions, some even wrote into spendable outputs, which actually consumed more resources.

Does this align more with the spirit of Bitcoin?

According to Bitcoin developer Greg Sanders' announcement and various developers' concurring opinions, we can know that first, Bitcoin Core has its own "standardness policy" during transaction propagation, which includes three levels of checks before transactions reach miners: first, to prevent "denial of service" attacks, rejecting transactions that consume far more hashing power, memory, or bandwidth than the fee; second, guiding wallet authors through policy to construct transactions that are low on fees and do not create redundant UTXOs; third, maintaining upgrade security—treating unknown opcodes or version bits as "non-standard" until the soft fork is formally activated.

OP_RETURN and its 80-byte limit are exactly the product of this concept: providing users with an output that can be proven "unspendable," enabling the storage of short commitments or hashes, while ensuring nodes do not include it in UTXO, thus avoiding on-chain "money-burning" garbage outputs.

However, now this soft limit has become a mere formality. On one hand, private mining pools and some centralized services do not enforce this rule at all; anyone wishing to write a large amount of data can bypass the policy—either by directly paying the miner, using bare-multisig, fake public keys, or even spendable scripts to hide the information—and still get the content included on the chain; on the other hand, constantly adding a bunch of blacklists will only evolve into a "cat and mouse" game, neither stopping the most basic data writing nor increasing the risk of inadvertently affecting user funds.

The developers of the Agree Side believe that after completely removing the 80-byte limit, nodes and wallets can enjoy two main practical benefits: first, the UTXO set is cleaner, with data stored in a clear "unspendable" OP_RETURN output, rather than tangled in fancy scripts or multiple transactions; second, nodes have a more consistent view on which transactions to propagate, aligning with what miners actually include in blocks, making fee estimation in wallets and compact block relay more reliable.

Bitcoin developers compared three proposals, with the current "removal" proposal having the most community support. More importantly, they see this removal of the OP_RETURN limit as the best embodiment of Bitcoin's "transparent and simple" spirit: when a strategy has lost its purpose but is still retained, it only adds complexity and friction; removing it makes node software lighter and purer, streamlining transaction propagation and block inclusion—miners only need to prioritize based on fee rates, letting the fee market naturally adjust competition.

Moreover, if there were to be a genuine threat of excessive data writes and resource consumption on-chain, the Bitcoin ecosystem has a well-tested set of "targeted" safeguards: signature operation limits, ancestor/descendant transaction limits, dust rules... These precise measures to combat specific abuse scenarios are far more flexible than the blanket "80-byte" rule, and can protect every node and user without hindering normal usage.

Will BTC Become an Altcoin?

One of the most prominent opponents is undoubtedly Luke Dashjr.

As a Bitcoin OG, who has previously stated that the "Ordinals Protocol is an attack on Bitcoin" and that "Script is garbage, a bug that can be fixed," Luke Dashjr has always been a vocal critic of the Ordinals Protocol.

This time, he remains firmly on the "conservative" side, believing that removing the OP_RETURN limit is a very crazy idea and an attack on Bitcoin. He and others argue that lifting the limit will lead to spam and higher transaction fees.

It is evident that the current debate and disagreement center around whether removing the 80-byte OP_RETURN limit will enhance transparency and simplify Bitcoin's data usage or if it will open the door to abuse, spam, and a diversion of Bitcoin's focus from finance.

Jason, Vice President of the Ocean Mining Pool, is one of the most vocal critics, losing sleep over this change and even stating, "This change will turn Bitcoin into a worthless altcoin."

Botanix Labs founder Willem Schroe expressed his belief that developers should see Bitcoin as a monetary system rather than a data storage platform. Another Bitcoin Core developer, Mechanic, shares a similar view: Bitcoin should not be used for arbitrary file storage, and every possible measure should be taken to ensure this.

Some highly influential Key Opinion Leaders (KOLs) in the industry, such as Samson Mow, are encouraging node operators not to upgrade their Bitcoin Core version or switch to Knots.

As of the time of writing, according to Clark Moody's data, the usage of Bitcoin Knots nodes has surpassed that of the latest version of Bitcoin Core nodes.

This is another challenge to Bitcoin's consensus, as has happened many times before. Of course, this also reminds us that while Bitcoin is more conservative compared to most networks, it is not immutable. After the next upgrade, we may also see a more concise and elegant protocol play than Ordinals, Atomics, and Runes.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia