Bitcoin Magazine

OP_RETURN Limits: Bitcoin’s Battle Over Arbitrary Data

An OP_RETURN debate flared up in the Bitcoin industry in recent weeks and has by now invaded most conversation spaces within the industry. The topic is rich and complex, and many people have strong opinions on the matter.

OP_RETURN is an opcode in Bitcoin’s scripting language used to store meta data or arbitrary data that is not relevant for bitcoin transaction validation, as such can be pruned by node runners without much issue, enabling more efficient management of spam while also giving developers a controlled environment to anchor data on chain. 

Taking a harm reduction approach to the problem of spam, the OP_RETURN controversy was recently triggered by a pull request submitted by Peter Todd to the Bitcoin Core repository. Proponents of the update seek to uncap the amount of arbitrary data that can be placed in the OP_RETURN by removing the mempool policy rule that restricts it to 80 bytes. By consequence, this moves the limit up to the consensus block size cap of 1MB of non-SegWit data. They argue that this limit is no longer effective at stopping spam and, on the contrary, is leading to more harmful behaviors such as stuffing data in UTXOs, which harm node runners.

Furthermore, the proposal removed the datacarrier flag, a configuration option that allowed node runners to choose which transactions to filter from their local mempool based on how much arbitrary data the OP_RETURN carried.

The opposition, led by Luke Dashjr, not only wants to keep the OP_RETURN limit in place and retain the datacarrier size but proposes further mempool policy restrictions on arbitrary data and “non-monetary” transactions on Bitcoin.

Both camps generally agree that arbitrary data on Bitcoin is a bad thing for the network. They also agree that filters cannot possibly filter all kinds of spam. What they disagree on is how effective these kinds of filters are in mitigating spam. They also disagree on the consequences of imposing or removing these filters from the network, their impact on the costs of running a node, and their impact on mining centralization.

Author’s note: Of course, not all proponents of the OP_RETURN changes agree with all of the arguments in favor of the pull request, and not all opponents agree with all of the arguments against it. This is just a general (and probably incomplete) overview of the various arguments out there.

In Support Of Removing the OP_RETURN Size Limit

Spearheaded by Peter Todd, though supported by many Bitcoin Core contributors, the removal of the OP_RETURN limit represents a harm reduction approach to the problem of spam and arbitrary data on Bitcoin.

Todd argues that the current OP_RETURN limit, initially placed over a decade ago to give spammers a safe and controlled space for arbitrary data, no longer serves its purpose as companies and enthusiasts have developed direct-to-miner private mempools, such as MARA’s Slipstream, that bypass mempool policy.

The OP_RETURN limit was put in place after Satoshi Nakamoto left, to protect the network from similar spam but during a very different era, when blocks were rarely full, much less boasting a high-fee environment. There were also few to no tools for pruning, and the software was very inefficient. Many optimizations have been implemented  over the last decade, and their cumulative effects influence this debate.

The OP_RETURN limit was thus more effective when it was first created and more difficult to bypass. Today, NFT and arbitrary data enthusiasts with ambitious projects, pressured out of the OP_RETURN space by the current mempool limit, have resorted to stuffing arbitrary data into the UTXO set instead. Unlike OP_RETURN or SegWit spaces, which can be reasonably pruned off nodes, the UTXO set is generally held in RAM, the most expensive form of memory. The UTXO set needs to be processed by nodes, to verify the supply of coins and be able to validate the integrity of new transactions, a fundamental piece of running a node, without which home nodes lose much of their value proposition. UTXO data stuffing as a result imposes significant costs on node runners by increasing initial block download, overall sync time, and hardware requirements that ultimately harm the decentralization of the Bitcoin network. 

Finally, supporters argue that miners are “rational economic actors,” an economics term meaning that to stay alive in a very competitive market, miners need to optimize for profits wherever possible. Thus, if mining consensus-valid non-standard transactions gives them an edge, they will take it.

Back in 2023, Luke Dashjr proposed a change that sought to apply datacarrier mempool policy to SegWit and Taproot arbitrary data, such as Inscriptions, further restricting the options for spammers. Peter Todd opposed the PR, explaining that “The transactions targeted by this pull request are a very significant source of fee revenue for miners. It is very unlikely that miners will give up that source of revenue. Censoring those transactions would simply encourage the development of private mempools – harmful to small miners – while making fee estimation less reliable.”

In Support of Removing the datacarrier Flag

Todd’s pull request did one more thing aside from removing the OP_RETURN limit: it also removed the datacarrier flag from the configuration options of node operators. Users of Bitcoin Core node software can control what transactions they relay through their node based on a configuration option called the datacarrier flag, which looks specifically at the amount of data inside the OP_RETURN, the default today being 80 bytes of arbitrary data.

Supporters argue that the flag is obsolete now and that the prevalence of tools like the mining pool MARA’s Slipstream program or Todd’s Libre Relay streamline the inclusion of consensus-valid transactions, even if they are “non-standard” by mempool policy.

Consensus-valid non-standard transactions are in conflict with mempool policy rules like the OP_RETURN limit but do not break any consensus rules and thus can be included in Bitcoin by a miner directly if the miner can simply be made aware of the transaction. Such systems already obsolete controversial filters, supporters argue, making the datacarrier flag irrelevant, particularly if the default OP_RETURN size limit is lifted.

Supporters argue that the flag only gives users the illusion of control and is a “footgun” – a tool that is dangerously easy to misuse – and in this case has no utility to the user.

Finally, removing the datacarrier flag alongside the OP_RETURN limit can remove a recurring point of conflict and controversy for Bitcoin Core, as filter-supporting Bitcoin maximalists are not the only ones with an opinion on the matter or capable of rallying the internet to oppose a pull request.

In 2023, a pull request was made to Bitcoin Core that sought to change the default mempool policy around routing bare multisig transactions. This is an old standard that is used today by NFT protocols such as Stamps, among others, to ensure their arbitrary data easily makes it to the chain and, better yet, cannot be easily pruned. The pull request quickly devolved into an internet flame war between “spammers” and supporters of the change, pausing its integration into Bitcoin Core in a similar way as Todd’s pull request did last week.

By removing the datacarrier flag, which supporters argue is irrelevant anyway, drama of this sort can be put to bed, and Bitcoin Core contributors can move on to other, more pressing issues, they argue.

In Opposition to Removing the OP_RETURN Size Limit

The opposition – colloquially known as the Filterors – and led by long-time Bitcoin Core contributor Luke Dashjr, argue that removing the OP_RETURN size limit is a surrender to the spammers, that perfect filters are not what is needed, rather that the mere act of filtering sends a message to companies or projects looking to build arbitrary data-reliant systems on top of Bitcoin. The message is: go build that somewhere else or find a better way to do it.

They argue that Bitcoin is a network for monetary transactions only, that anything outside of that definition is spam. Monetary transactions are, in their view, Bitcoin transactions that seek only to transfer bitcoin-denominated value between two users, with goods and services transferred off-chain in return.

According to Chris Guida, a Lightning developer and Bitcoin Knots supporter, there are roughly two formal definitions for monetary transactions on Bitcoin.

“I think there are effectively two different definitions: one has to do with whether the transaction is actually using Bitcoin as a payment rail, and not a database for scammy ‘products’,” referring to NFTs, adding “and the other definition is, effectively, ‘does it fit within 40/80 bytes’ in OP_RETURN. If neither of these standards apply, they consider it spam.”

NFT trades or arbitrary data used to anchor Layer 2 protocols on top of Bitcoin do not count as monetary transactions in this sense and thus are considered spam, even if these Layer 2s might be conducting financial transactions of various kinds.

Furthermore, Filterors argue that Bitcoin Core should be actively looking for ways to discourage this kind of behavior. They argue that spammers moving to UTXO stuffing is evidence that the filters work, in that the pressure effectively leads them to find other ways to spam the network. In other words, if the filters did not work, then spammers would not be looking for more expensive terrain on which to build their spam systems, such as the UTXO set.

Thus, not only should the OP_RETURN limit be kept, but it should probably be shrunk further, perhaps back to the historical 40 bytes. Furthermore, the datacarrier flag should be expanded to govern Segregated Witness and Taproot transactions, which are uncapped for arbitrary data up to the block size limit and are being exploited by spammers, the most prominent of which are Inscriptions.

Finally, the Filterors affirm that systems like Todd’s Libre Relay or MARA’s Slipstream can be fought in various ways, and they do not intend to simply fold if Bitcoin Core continues with its current development path. The result has been growing interest in Bitcoin Knots, the alternative implementation of Bitcoin maintained by Luke Dashjr, among others, to empower Bitcoin users to run their own filters as they see fit and fight the spam. As of the time of writing and according to Luke’s network analysis, over 5% of the Bitcoin nodes are running Bitcoin Knots.

In Opposition to Removing the datacarrier Flag

Filterors and Bitcoin Knots enthusiasts also defend the datacarrier flag on principle. They argue that with sufficient numbers, coordinated node runners have a path to successfully filter a certain set of spam, going as far as to argue for the expansion of what the datacarrier flag governs, as seen in that pull request from 2023 by Luke Dashjr. In it, SegWit and Taproot arbitrary data storage capabilities would also be limited by the node runner-controlled datacarrier flag; they currently are not.

This point, in particular, has resonated with many people, as seen by the growing numbers of Bitcoiners running the Bitcoin Knots implementation of Bitcoin, which includes mempool policy changes of this sort while keeping all other Bitcoin Core code intact.

Some Bitcoin Knots supporters, like Chris Guida, are starting to talk about user-controlled relay policies or “modular filters” which can be created from refactoring mempool policy code and updated to follow certain actively managed templates – a kind of automated spam filter algorithm that users could choose from a provider. 

On X he argued “It is often claimed that filtering spam is a “cat-and-mouse game” where somehow the filterers are at a disadvantage.

I think that’s absurd. We can create filters as fast as new fungible token metaprotocols can create their new tx formats, before they even hit mainnet.”

While even Filterors recognize that there are limits to spam control, they maintain that a hostile environment to spam-related software systems and business models is a good thing and one that needs to be maintained to deter bad behavior, even if the more price-insensitive versions will nevertheless go direct to miners and pay to make it into a block.

This post OP_RETURN Limits: Bitcoin’s Battle Over Arbitrary Data first appeared on Bitcoin Magazine and is written by Juan Galt.