Removing the OP_RETURN restriction

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.

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 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