Author: Jaleel Jialiu
In recent days, the Internet has been abuzz with the proposal to remove the OP_RETURN restriction - this is a proposal made by Bitcoin Core OG developer Peter Todd.
Although there are many doubts in the community about the change to OP_RETURN, according to an announcement posted on GitHub on May 5 by Bitcoin developer and Blockstream core contributor Greg Sanders (nicknamed "instagibbs"): 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 a ledger that can never be tampered with, and every transaction is like writing a line of record on it.
OP_RETURN is like sticking a "note" on the edge of a book page - you can write a few dozen words or a small piece of data into it. This note is marked as "read-only" by the system. Others cannot use it as money, and it will not have any impact on other "money" records in the ledger.
The reason for having such a "note" function is that sometimes people want to permanently pin some additional information (such as legal proof, short messages, anniversaries or even confessions) on the chain, but do not want to occupy the UTXO space used to store "tradable" bitcoins. With OP_RETURN, this information is thrown into a drawer like waste paper - the node only leaves traces and does not occupy the inventory, and the "available money" on the chain is still clean and neat.
In the past, in order to prevent people from writing long "notes" and clogging up the network, Bitcoin Core only allowed one OP_RETURN in each transaction by default, and a maximum of 80 bytes of content could be stored. If the content exceeded, the node would directly refuse to relay it and would not help package it.
Now, the 80-byte and single-line limit are gone - you can write as long as you want, as many notes as you want, and nodes will automatically relay and miners will be happy to package them.
But the fact is that people have been working around 80 bytes for a long time.
Before the OP_RETURN limit, there were ways to bypass the 80-byte limit. No matter how strict the filtering and relay strategies were, they could not stop people who really wanted to write data on Bitcoin. Because only miners and handling fees determine which transactions are put on the chain, giving miners higher rewards will naturally tend to pack more transactions, and the gameplay will not change due to node strategies.
For example, the well-known Tapoort Wizz NFT, a nearly 4M image, filled up an entire block. In addition, the Ordinals inscriptions and runes used various "detours and workarounds" to bypass restrictions. Some were even written into spendable outputs, which took up more resources.
Is this more in line with the spirit of Bitcoin?
According to the announcement released by Bitcoin developer Greg Sanders and the opinions of various developers, we can know that first of all, Bitcoin Core has its own "standardness policy" in the transaction propagation (relay) stage, which is used to perform three levels of checks before the transaction reaches the miners: first, to prevent "denial of service" attacks and reject transactions whose computing power, memory or bandwidth consumption far exceeds the transaction fee; second, through strategies to guide wallet authors to construct transactions that save transaction fees and do not create redundant UTXO; third, to retain upgrade security - treating unknown opcodes or version bits as "non-standard" until the soft fork is officially activated.
OP_RETURN and its 80-byte upper limit are the product of this concept: giving users a provably "unspendable" output that can store a small commitment or hash and prevent nodes from counting it as UTXO, thereby avoiding "losing money" garbage output on the chain.
But now this soft limit has become useless. On the one hand, private mining pools and some centralized services do not enforce this rule at all. Anyone who wants to write a large amount of data can bypass the strategy - either paying miners directly, or hiding the information with bare-multisig, fake public keys, or even spendable scripts - and still put the content they want to write on the chain; on the other hand, adding a bunch of blacklist filters at every turn will only turn into a "cat and mouse" game, which can neither stop the most basic data from being written, nor increase the risk of accidentally damaging user funds.
Developers on the supporting side believe that after completely removing the 80-byte limit, nodes and wallets can enjoy two major practical benefits: first, the UTXO set is cleaner, and the data is packed into a clearly "unspendable" OP_RETURN output, rather than entangled in various fancy scripts or multiple transactions; second, nodes are more unified in what they "say yes" to about which transactions to propagate, and are consistent with what miners actually package, and wallet fee estimation and compact block relay are more reliable.
Bitcoin developers compared three solutions, and the "cancellation" solution currently adopted has the greatest momentum in the community. More importantly, they believe that the cancellation of the OP_RETURN restriction is the best interpretation of Bitcoin's "transparent simplicity" spirit: when a strategy has lost its due effect, but is still retained, it will only increase complexity and friction; removing it will make the node software lighter and purer, and the propagation and packaging of each transaction will not need to be roundabout - miners only need to determine the priority based on the level of handling fees, and the rate market will naturally adjust the competition of various demands.
Once the threat of excessive writing and resource consumption really appears on the chain, the Bitcoin ecosystem still has a whole set of tested "targeted" protections: signature operation restrictions, upper limits on the number of predecessor and descendant transactions, dust rules... These methods of precisely combating specific abuse scenarios are much more flexible than the one-size-fits-all "80 bytes", and can better protect every node and user without affecting normal use.
Will BTC become an altcoin?
The most well-known opponent is probably Luke Dashjr.
As a Bitcoin OG, Luke Dashjr, who once said that "the Ordinals protocol is an attack on Bitcoin" and "the inscription is garbage, it is a bug and can be fixed", has always been an outspoken critic of the Ordinals protocol in the past.
This time, he still firmly stood on the "conservative" side, believing that canceling the OP_RETURN limit was a very crazy thing and an attack on Bitcoin. He and others believed that canceling the limit would lead to spam and higher transaction fees.
It can be seen that the focus of the current debate and disagreement is whether removing the 80-byte OP_RETURN limit will increase transparency and simplify Bitcoin's data use, or whether it will open the door to abuse, spam, and Bitcoin's deviation from its financial focus.
Jason, vice president of Ocean Mining Pool, is one of the most vocal critics. He has lost sleep over this and even said bluntly: "This change will turn Bitcoin into a worthless altcoin."
Willem Schroe, founder of Botanix Labs, said he believes developers should use Bitcoin as a currency system rather than a data storage platform. Another Bitcoin core developer, Mechanic, has a similar view: Bitcoin should not be used for arbitrary file storage, and all possible measures should be taken to ensure this.
Some influential KOLs in the industry, such as Samson Mow, are encouraging node operators not to upgrade their Bitcoin Core versions, or to use Knots instead.
As of writing, according to data from Clark Mood, Bitcoin Knots nodes are being used more than the latest version of Bitcoin Core nodes.
This is another challenge to Bitcoin consensus, just like it has happened many times before. Of course, this also makes us realize that although Bitcoin is more conservative than most networks, it is not immutable. After the next upgrade, we may also get a more concise and elegant protocol than Ordinals, Atomicals, and Runes.
