OP_RETURN Restrictions: A battle for any data of Bitcoin

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

In recent weeks, a debate about OP_RETURN has erupted in the Bitcoin industry, which has now swept 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 that is used to store metadata or arbitrary data that is not related to Bitcoin transaction verification. Therefore, node runners can prune it without causing too much problem, thus managing spam more efficiently while providing developers with a controlled 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 code base. The update's supporters attempt to remove the limit on any amount of data that can be put into OP_RETURN by deleting the memory pool policy rule (limiting any data in OP_RETURN to 80 bytes). Therefore, this will raise the limit to the upper limit of consensus block size, i.e., non-isolated witness data 1MB. They believe that such restrictions are no longer effective in blocking spam, but instead lead to more harmful behavior, such as filling data in UTXO, which harms the interests of node operators.

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

The opposition led by Luke Dashjr not only wants to retain the OP_RETURN limit and datacarrier size, but also proposes a policy of further limiting arbitrary data and "non-currency" transactions in the bitcoin memory pool.

Both camps generally believe that arbitrary data on Bitcoin is not good for the network. They also think that filters cannot filter all types of spam. They differ in the effectiveness of these filters in reducing spam. They also disagree on the consequences of forcing or removing these filters from the network, their impact on the cost of nodes running, and their impact on mining centralization.

Author's Note: Of course, not all OP_RETURN changes agree with all arguments that support the pull request, nor are they all arguments that oppose the request. This article is just a summary of various arguments (maybe incomplete).

Support removal of OP_RETURN size limit

This proposal, led by Peter Todd and supported by numerous Bitcoin Core contributors, represents a way to reduce the harm of bitcoin spam and arbitrary data.

Todd believes that the current OP_RETURN limit was originally set up more than a decade ago to provide a safe and controllable arbitrary data space for spammer senders, but it is no longer applicable, as some companies and enthusiasts have developed private memory pools directly for miners, such as MARA's Slipstream, which can bypass memory pooling policies.

The OP_RETURN restriction was established after Satoshi Nakamoto left and was designed to protect the network from similar spam data, but the era was very different from now, when blocks were rarely full, let alone a high-cost environment. At that time, there were almost no tools for block trimming, and the software was very inefficient. Many optimization measures have been implemented over the past decade, and their cumulative effects have affected this debate.

Therefore, the OP_RETURN limit is more efficient and harder to bypass when initially created. Today, NFT and arbitrary data enthusiasts have been ambitious projects, under the pressure of current memory pool restrictions, have to give up the OP_RETURN space and instead stuff arbitrary data into the UTXO set. Unlike OP_RETURN or SegWit spaces, which can be reasonably removed from nodes, UTXO sets are usually stored in RAM, which is the most expensive form of memory. The UTXO set needs to be processed by the node to verify the money supply and be able to verify the integrity of the new transaction, which is the basic element of running the node, without which the master node will lose most of its value proposition. Therefore, UTXO data tucking will increase initial block download, overall synchronization time and hardware requirements, thus bringing huge costs to node operators and ultimately harming the decentralization of the Bitcoin network.

Finally, supporters believe that miners are “rational economic actors,” an economic term that means that in order to survive in a highly competitive market, miners need to optimize profits as much as possible. So if mining non- standard transactions that meet the consensus can give them an advantage, they will seize the opportunity.

Back in 2023, Luke Dashjr proposed a change that attempted to apply data carrier memory pooling strategies to arbitrary data (such as inscriptions) of quarantine witnesses and Taproot, further limiting spammers’ options. Peter Todd opposes the PR, explaining: "The transactions targeted by this pull request are a very important source of income for miners. Miners are unlikely to give up on this source of income. Reviewing these transactions will only encourage the development of private memory pools - which are harmful to small miners - while reducing the reliability of cost estimates."

Supports removal of data carrier logos

Todd's pull request does one more thing in addition to removing the OP_RETURN limit: it also removes the data carrier flag from the node operator's configuration options. Users of Bitcoin Core Node Software can control 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 OP_RETURN, and currently has a default value of 80 bytes of arbitrary data.

Proponents believe that the logo is now outdated and the popularity of tools like Mining Pool MARA's Slipstream program or Todd's Libre Relay simplifies the inclusion of consensus-effective transactions, even if they do not meet the "standard" of memory pooling strategies.

A non-standard transaction with a consensus conflicts with memory pool policy rules such as OP_RETURN restrictions, but does not violate any consensus rules, so as long as the miner is aware of the transaction, it can be included directly in Bitcoin. Supporters believe that such systems have eliminated controversial filters, making the data carrier flag irrelevant, especially after the default OP_RETURN size limit is removed.

Supporters believe that the logo only gives the user an illusion of control, and is a "gun technique" - a tool that is extremely abused - in this case is useless to the user.

Finally, removing the data carrier flag together with the OP_RETURN restriction can eliminate recurring conflicts and controversy points of Bitcoin Core, because Bitcoin extremists who support filters are not the only ones who have opinions on the matter or have the ability to gather forces on the Internet against pull requests.

In 2023, someone issued a pull request to Bitcoin Core, trying to change the default memory pool policy around routing naked multi-signature transactions. This is an ancient standard that is now used by NFT protocols such as Stamps to ensure that any of its arbitrary data can be easily entered on the chain, and, better yet, cannot be easily modified. The pull request quickly evolved into an online war of words between "spapers" and supporters, causing its integration with the Bitcoin core to be suspended, just like Todd's pull request last week.

They believe that by removing the data carrier logo (which supporters think is irrelevant), such farce can be calmed down, and Bitcoin core contributors can focus their energy on other more pressing issues.

Oppose removal of OP_RETURN size limit

The opposition — commonly known as "Filterors" — is led by Luke Dashjr, a long-time contributor to Bitcoin core. They believe that removing the OP_RETURN size limit is a surrender to spammers, and that a perfect filter is not necessary. The mere filtering behavior sends the message to companies or projects that want to build arbitrary data-dependent systems on Bitcoin: go build elsewhere, or look for a better way.

They believe that Bitcoin is just a currency trading network, and anything beyond that definition is spam. In their view, currency transactions refer to Bitcoin transactions, whose purpose is to transfer value denominated in Bitcoin between two users and return on the off-chain transfer of goods and services.

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

“I think there are actually two different definitions: one is about whether the transaction actually uses Bitcoin as a payment channel, rather than a database of scam 'products',” he refers to NFT, adding, “the other definition is actually 'whether it meets 40/80 bytes in OP_RETURN'. If neither of these standards apply, they would consider it as spam.”

NFT transactions or arbitrary data used to anchor the second layer protocol on top of Bitcoin are not considered currency transactions in this sense and are therefore considered spam, even if these second layer protocols may be conducting various financial transactions.

Furthermore, filter proponents believe that Bitcoin core should actively find ways to prevent this behavior. They believe spammers turn to UTXO fill, which proves that filters work because the pressure actually prompts them to find other ways to spam the network. In other words, if the filter doesn't work, spammers won't look for more expensive areas to build their spam systems, such as UTXO sets.

Therefore, the limit of OP_RETURN should not only be preserved, but should also be further reduced, perhaps to the 40 bytes of history. Additionally, the data carrier logo should be extended to manage isolation witnesses and Taproot transactions. These two transactions are not restricted within the block size limit and are being exploited by spammers, the most prominent of which is the Inscriptions attack.

Finally, filters confirmed that systems like Todd's Libre Relay or MARA's Slipstream can be fought in a variety of ways, and they wouldn't give up easily if the Bitcoin core continues to follow the current path of development. As a result, people are increasingly interested in Bitcoin Knots. The Bitcoin stale is an alternative implementation of Bitcoin maintained by Luke Dashjr and others, aiming to enable Bitcoin users to run filters as they wish and fight spam. As of the time of writing, more than 5% of Bitcoin nodes are running Bitcoin junctions according to Luke's network analysis.

Oppose removal of data carrier logo

Filters and Bitcoin Knots enthusiasts also defend the data carrier logo in principle. They believe that as long as there is enough quantity, coordinated node operators can successfully filter specific types of spam and even advocate extending the jurisdiction of data carrier logos, as reflected in Luke Dashjr's pull request submitted in 2023. In this request, the SegWit and Taproot arbitrary data storage functions will also be limited by the data carrier flags controlled by the node operator; this is not the case at this time.

This resonates in particular with many people, with more and more Bitcoin users running Bitcoin’s Bitcoin Knots implementation, which includes such memory pool strategy changes while retaining all other Bitcoin core code.

Some Bitcoin Knots supporters, such as Chris Guida, have begun discussing user-controlled relay strategies or “modular filters.” These filters can be created by refactoring the memory pool policy code and updated based on certain actively managed templates—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 filters are at a disadvantage to some extent.

I think this is ridiculous. We can create filters as quickly as the new interchangeable token mon protocol creates new transaction formats, even before they go online to the mainnet. ”

While filter proponents also acknowledge that spam control has limitations, they insist that it is a good thing to maintain a hostile environment to spam- related software systems and business models, and that it needs to be maintained to prevent bad behavior, even if the versions that are less price- sensitive will still be sent directly to miners and paid to pack them into chunks.