Bitcoin and the Battle Over Arbitrary Data

The following are some of the ways to get in touch with each other OP_RETURN In recent weeks, the Bitcoin debate has exploded in industry. There are many opinions and a lot of complexity to this topic.

The OP_RETURN opcode is used in Bitcoin scripting to store meta-data or other arbitrary data not related to bitcoin transactions. This data can easily be removed by the node runners, which allows for more efficient spam management and gives developers an environment where they can anchor their data. 

Harm reduction is the best way to tackle the problem. spamThe OP_RETURN debate was sparked by a recent pull request made by Peter Todd for the Bitcoin Core repository. The update aims to remove the cap on the amount of arbitrary information that can be stored in the OP_RETURN. mempool It is a policy restriction that it must be 80 bytes. This limits the size of the block to 1MB for non-SegWit non-SegWit. This limit, they claim, no longer effectively stops spam. Instead, it leads to other harmful behaviors, such as stuffing UTXOs with data, harming node runners.

Further, the proposal eliminated the datacarrier, a configuration setting that enabled node runners choose what transactions they wanted to remove from their mempool based solely on the amount of data carried by the OP_RETURN.

Luke Dashjr is the leader of the opposition. He wants not only to retain the OP_RETURN limitation and the size limit for data carriers, but he also suggests further restrictions in the mempool’s policy on arbitrary and illogical data. “non-monetary” Bitcoin transactions.

Both sides agree in general that Bitcoin suffers from arbitrary data. The two camps also agreed that no filter could possibly be able to block all types of spam. The disagreement is over the effectiveness of these types of filters in mitigating unwanted spam. Also, they disagree over the effects of adding or removing filters, the cost of operating a network and the effect on mining.

Nota scrittor: There is no doubt that not all supporters of OP_RETURN agree with the entire argument for the pull request and not all critics agree with the whole argument against it. Here is an overview (and most likely incomplete) of some of the different arguments.

Peter Todd spearheaded the effort, but many Bitcoin Core developers supported it. The removal of the OP_RETURN limitation is a way to reduce the amount of spam on Bitcoin and arbitrary data.

Todd argues the current OP_RETURN limitation, originally placed more than a decade to provide spammers with a controlled and safe space for arbitrary information, does not serve its purpose, as many companies and enthusiasts developed private mempools that are accessible directly by miners, like MARA’s SlipstreamThere are some apps that do not follow the policy of mempool.

The OP_RETURN limitation was implemented after Satoshi left to protect the network against similar spam, but in a different era when blocks rarely were full and even less so boasted a high fee environment. Also, there were few tools to prune and the software itself was extremely inefficient. Many optimizations have been implemented  over the last decade, and their cumulative effects influence this debate.

The OP_RETURN limitation was therefore more effective and difficult to circumvent when first introduced. NFT and arbitrary users who have ambitious projects but are unable to fit their data in the OP_RETURN area due to the current limit on mempools, now stuff arbitrary data instead into the UTXO. Unlike OP_RETURN spaces or SegWit, that can be pruned reasonably off of nodes. The UTXO Set is typically held in RAM. Nodes must process the UTXO data to confirm the coin supply and validate new transactions. This is a crucial part of operating a node without which they lose much value. UTXO stuffing imposes substantial costs to node runners, increasing the initial block download time and the overall sync times. This ultimately damages the decentralization. 

Some supporters also argue that the miners should be protected. “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.”

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.

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.

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.