OP_RETURN Limitations: The Dispute over Any Data in Bitcoin

Author: Juan Galt, Bitcoin Magazine; Translated by: Wu Zhu, Golden Finance

In recent weeks, there has been a debate in the Bitcoin industry regarding OP_RETURN, which has currently swept through most of the discussion space in the industry. This topic is rich and complex, and many people have strong opinions on it.

OP_RETURN is an opcode in the Bitcoin scripting language used to store metadata or arbitrary data that is not related to Bitcoin transaction validation. Therefore, node operators can prune it without causing significant issues, allowing for more efficient management of spam while providing developers with a controllable environment to anchor data on the chain.

To reduce the harm of spam, the OP_RETURN controversy was recently triggered by a pull request submitted by Peter Todd to the Bitcoin Core codebase. Supporters of the update are attempting to lift the restriction on the amount of arbitrary data that can be placed in OP_RETURN by removing the mempool policy rule that limits any data in OP_RETURN to 80 bytes. Therefore, this would elevate the limit to the consensus block size limit, which is 1MB of non-segregated witness data. They argue that this restriction is no longer effective in preventing spam and may instead lead to more harmful behaviors, such as filling UTXO with data, thereby harming the interests of node operators.

In addition, the proposal also removes the datacarrier flag, which is a configuration option that allows node operators to choose which transactions to filter from their local memory pool based on the amount of data carried by OP_RETURN.

The opposition led by Luke Dashjr not only wants to retain the OP_RETURN limits and datacarrier size but also proposes to further restrict the policy on arbitrary data and "non-monetary" transactions in the Bitcoin mempool.

Both camps generally believe that any data on Bitcoin is detrimental to the network. They also believe that filters cannot filter out all types of spam. Their disagreement lies in the effectiveness of these filters in reducing spam. They also have differing opinions on the consequences of enforcing or removing these filters from the network, their impact on node operating costs, and their effect on mining centralization.

Author's note: Of course, not all supporters of the OP_RETURN changes agree with all the arguments in favor of this pull request, nor do all opponents agree with all the arguments against this request. This article is simply a summary of various arguments (which may not be exhaustive).

Support removal of OP_RETURN size limit

This proposal led by Peter Todd and supported by many Bitcoin Core contributors represents a way to reduce the harm of garbage data and arbitrary data in Bitcoin.

Todd believes that the current OP_RETURN limitation was established over a decade ago to provide a secure and controllable arbitrary data space for garbage data senders, but it is no longer applicable as some companies and enthusiasts have developed private memory pools directly targeting miners, such as MARA's Slipstream, which can bypass the memory pool strategies.

The OP_RETURN restriction was established after Satoshi Nakamoto left, aimed at protecting the network from the impact of junk data. However, the era at that time was completely different from now; back then, blocks were rarely full, let alone in a high-fee environment. There were almost no tools available for block pruning, and the software was very inefficient. Over the past decade, many optimizations have been implemented, and their cumulative effect has influenced this debate.

Therefore, the OP_RETURN limitation was more effective at the time of its initial creation and is harder to circumvent. Nowadays, due to the pressure from current mempool limitations, ambitious projects by NFT and arbitrary data enthusiasts have no choice but to abandon OP_RETURN space and instead cram arbitrary data into the UTXO set. Unlike OP_RETURN or SegWit space (which can be reasonably removed from nodes), the UTXO set is typically stored in RAM, which is the most expensive form of memory. The UTXO set needs to be processed by nodes to verify the currency supply and to be able to verify the integrity of new transactions, which are fundamental elements of running a node; without these elements, the main node would lose most of its value proposition. Therefore, the stuffing of UTXO data increases the initial block download, overall synchronization time, and hardware requirements, imposing significant costs on node operators and ultimately harming the decentralization of the Bitcoin network.

Finally, supporters argue that miners are "rational economic actors," a term in economics that refers to the need for miners to optimize profits as much as possible in order to survive in a competitive market. Therefore, if mining non-standard transactions that comply with the consensus can provide them with an advantage, they will seize the opportunity.

Back in 2023, Luke Dashjr proposed a reform aimed at applying the data carrier memory pool strategy to arbitrary data in Segregated Witness and Taproot (such as inscriptions), thereby further limiting the options for spammers. Peter Todd opposed this PR, explaining: "The transactions targeted by this pull request are a very important source of fee revenue for miners. Miners are unlikely to give up this source of income. Reviewing these transactions would only encourage the development of private memory pools—which is harmful to small miners—while reducing the reliability of fee estimation."

Support for removing data carrier flags

Todd's pull request did another thing besides removing the OP_RETURN limitation: it also removed the data carrier flag from the configuration options for node operators. Users of the Bitcoin Core node software can control the transactions relayed through their nodes based on a configuration option called the data carrier flag, which is specifically used to control the amount of data in the OP_RETURN, with the current default value being 80 bytes of arbitrary data.

Supporters believe that the logo is now outdated, and the popularity of tools like the Slipstream program from the mining pool MARA or Todd's Libre Relay has simplified the inclusion of consensus-valid transactions, even if these transactions do not conform to the "standards" of memory pool policies.

The non-standard transaction and mempool strategy rules (such as OP_RETURN restrictions) conflict with effective consensus, but do not violate any consensus rules, so as long as miners are aware of the transaction, they can directly include it in Bitcoin. Proponents argue that such systems have rendered the controversial filters obsolete, making the data carrier flag irrelevant, especially after the removal of the default OP_RETURN size limit.

Supporters believe that the symbol only gives users an illusion of control, a "gun" - a tool that is easily abused - which is of no use to users in this case.

Finally, removing the data carrier flag along with the OP_RETURN restriction can eliminate the recurring conflicts and points of contention within Bitcoin Core, as Bitcoin extremists who support filters are not the only ones who have opinions on this matter or the ability to rally opposition against pull requests online.

In 2023, someone made a pull request to Bitcoin Core, attempting to change the default mempool policy regarding routing bare multisig transactions. This is an old standard, now used by NFT protocols like Stamps, to ensure that their arbitrary data can easily enter the chain and, even better, cannot be easily modified. This pull request quickly evolved into an online spat between "spam senders" and supporters, leading to a pause in its integration with Bitcoin Core, just like Todd's pull request last week.

They believe that by removing the data carrier markers (which supporters argue are irrelevant), this kind of farce can be quelled, allowing Bitcoin core contributors to focus their energy on other more pressing issues.

Oppose Removing the Size Limit on OP_RETURN

The opposition, commonly referred to as "Filterors," is led by long-time Bitcoin Core contributor Luke Dashjr. They argue that removing the OP_RETURN size limit is a capitulation to spammers, and that a perfect filter is not necessary; simply filtering behavior sends a message to companies or projects that wish to build arbitrary data-dependent systems on Bitcoin: build elsewhere, or find a better way.

They believe that Bitcoin is just a currency trading network, and anything beyond that definition is spam. In their view, currency trading refers to Bitcoin transactions, which aim solely to transfer Bitcoin-denominated value between two users, with the transfer of goods and services off-chain as the reward.

According to Chris Guida, a developer of the Lightning Network and supporter of Bitcoin Knots, there are roughly two formal definitions of currency transactions on Bitcoin.

"I believe there are actually two different definitions: one definition is whether the transaction genuinely uses Bitcoin as a payment channel, rather than a database for a scam 'product,'" he referred to NFTs, adding, "the other definition is actually 'does it conform to the 40/80 bytes in OP_RETURN.' If neither of these standards applies, they will regard it as spam."

NFT transactions or arbitrary data anchored on the second layer protocol over Bitcoin are not considered monetary transactions in this sense, and are therefore regarded as spam, even though these second layer protocols may be conducting various financial transactions.

Moreover, filter supporters believe that Bitcoin Core should actively seek ways to prevent this behavior. They argue that spammers turning to UTXO filling proves the filter's effectiveness, as the pressure actually prompts them to look for other ways to spam the network. In other words, if the filter were ineffective, spammers would not seek out more expensive areas to build their spam systems, such as the UTXO set.

Therefore, the limitation of OP_RETURN should not only be retained but also further reduced, perhaps restored to the historical 40 bytes. Additionally, the data carrier flag should be extended to manage Segregated Witness and Taproot transactions. These two types of transactions are unrestricted within the block size limit and are being exploited by spammers, with the most prominent being the Inscriptions attack.

Finally, filterers confirm that systems like Todd's Libre Relay or MARA's Slipstream can be countered in a number of ways, and that they won't give up easily if Bitcoin Core continues on its current path. As a result, there is a growing interest in Bitcoin Knots. Bitcoin knots are alternative implementations of Bitcoin maintained by Luke Dashjr et al., and are designed to allow Bitcoin users to run filters as they wish, and fight spam. As of this writing, according to Luke's network analysis, more than 5% of Bitcoin nodes are running Bitcoin knots.

Oppose the removal of data carrier marks

Filterers and Bitcoin (Bitcoin Knots) enthusiasts also defend the data carrier flag in principle. They argue that, with enough of them, coordinated node operators can successfully filter out specific types of spam and even advocate for expanding the jurisdiction of data carrier flags, as exemplified by Luke Dashjr's 2023 pull request. In this request, Segregated Witness (SegWit) and Taproot arbitrary data store capabilities will also be limited by the data carrier flag controlled by the node operator; This is not the case at the moment.

This point resonates especially with many people, as more and more Bitcoin users are running the Bitcoin implementation (Bitcoin Knots), which includes such memory pool policy changes while retaining all other Bitcoin core code.

Some supporters of Bitcoin Knots (, such as Chris Guida, have begun discussing user-controlled relay strategies or "modular filters." These filters can be created by reconstructing the mempool policy code and updated according to certain actively managed templates—this is an automated spam filtering algorithm that users can choose from providers.

On X, he argued: "People often say that filtering spam is a 'cat-and-mouse game,' and that filters are at a disadvantage to some extent.

I think this is ridiculous. We can create filters as quickly as creating new trading formats like the new interchangeable token Yuan protocol, even before they go live on the mainnet.

Although supporters of filters acknowledge the limitations of spam control, they insist that maintaining a hostile environment towards spam-related software systems and business models is a good thing, and that this environment needs to be upheld to deter bad behavior, even if those versions that are less price-sensitive will still be sent directly to miners and paid to be packed into blocks.