What is old is new again.
Bitcoiners have been having a debate about OP_RETURN – a Bitcoin script that stores data inside a transaction – and its data limit since the dawn of Bitcoin. The first major argument dates back to 2014 during the aptly named OP_RETURN Wars. At the time, users were using OP_RETURN for non-financial reasons – in particular the Counterparty Protocol, a Bitcoin NFT platform that predates Ordinals. If we go back and read the forums & mailing list, we see many of the exact same cast of characters arguing about it today, such as Luke Dashjr, Pieter Wuille, Peter Todd, and Gregory Maxwell.
The current filter fight began as a fairly normal Bitcoin developer mailing list discussion two weeks ago. When developer Peter Todd submitted a relevant pull request #32359 to the Bitcoin Core Github, comments turned accusatory and hostile, resulting in forum moderators timing out users and eventually locking comments on the thread.
The follow up conversation that spilled into social media is too sprawling to adequately cover in a writeup. However, let’s try to break down the debate.
Clarification of Bitcoin terms for the OP_RETURN debate
- Valid transactions: Any transaction that is considered valid by Bitcoin consensus
- Standard transactions: A subset of valid transactions. When a Bitcoin Core node “sees” a Standard transaction it will relay that transaction to its connected nodes. Theoretically, that transaction will find its way to the node of a miner and eventually into a block.
- Nonstandard transactions: Valid transactions that are not relayed by the default standardness policies of a Bitcoin Core node.
- DoS transactions: Transactions which are valid but pose clear denial-of-service vectors to Bitcoin.
All of this is explained in a very helpful breakdown by Orangesurf that we recommend you read.
The OP_RETURN data limit expansion proposal
Peter Todd’s pull request proposes to relax Bitcoin Core’s relay policy by making the default size of an OP_RETURN transaction that a Core node relays the same as is allowed by Bitcoin Consensus (roughly 1MB). There are demonstrated and anticipated uses of OP_RETURN transactions larger than 83 bytes, which is currently the standardness rule for Core.
Todd’s proposal would not require a soft fork nor hard fork – it simply expands the types of transactions that would propagate freely through the network of Bitcoin nodes.
The discussion originated after Core contributor Antoine Poinsot read that Bitcoin rollup Citrea, due to existing OP_RETURN standardness of 83 bytes, opted to post data to Bitcoin with one OP_RETURN and two unspendable outputs. These two unspendable outputs would in theory just continue to accumulate over time, and a design goal of Bitcoin Core has been to limit the growth of the UTXO set when possible.
Relaxing the OP_RETURN limit would theoretically allow Citrea and other projects to make design decisions that do not result in UTXO set growth and discourage miners from taking transactions directly (via out-of-band payments) instead of receiving them organically through the network of nodes.
To be clear: the proposal does not pertain to Inscriptions or Ordinals, although the discussion quickly revived the heated and wandering arguments over arbitrary data on Bitcoin, specifically JPEGs.
Arguments against relaxing OP_RETURN data limits and filtering data
Most of the arguments against the pull request are from the “filter” camp and from the prominent voices at Ocean Pool. Some of the arguments are technical, some are philosophical, and most are personal about the motivations behind the pull request and Bitcoin Core contributors. Those against the PR are also generally conspiratorial about Core and “spammers” being bought out and intending to harm Bitcoin.
Technical arguments say that “spam” is undesirable and should be discouraged:
“We don’t need to make sure no spam ever reaches the blockchain. That is, of course, impossible. All we need to do is show active hostility to the spammers, and the worst schemes (the ones that rely on a consistent transaction format) will be impossible to maintain, and will therefore lose funding,” argues Bitcoin Developer Chris Guida.
Philosophical arguments are difficult for me to pin down, but generally they say that Bitcoin is for financial data only and that Bitcoin should not be a “database” or for “data storage.”
It would not be intellectually honest to leave out that there is data on Bitcoin that is reprehensible, particularly child abuse. People have been putting these evil things on Bitcoin for over a decade, but the rise of Ordinals saw a handful of instances of more “complete” types of this data stored as actual full image files (I personally had to censor some of these early on in Ordinals before there were automated tools). Critics of this practice are rightfully concerned about the existence of this information on Bitcoin.
Another philosophical argument is that of consent, in that noderunners do not consent to non-financial data such as JPEGs being stored on their nodes. Luke Dashjr believes that storing JPEGs on users nodes is the equivalent “rape.” This is not a mischaracterization of his opinion and he, as well as others, have made it very clear this is their literal position.
The leading voices against Todd’s pull request and in support of filters make it very clear that they believe it is a fundamental change in what Bitcoin is and that it is the “Quickest way to kill the Bitcoin project.” Ocean Pool’s Bitcoin Mechanic was clear that this relaxed relay policy is a “death to Bitcoin,” and that “we may have to go down fighting it” because it “undermines people running nodes.”
Argument for relaxing the OP_RETURN data limit
The primary two arguments for relaxing the limit are that it discourages users from handing nonstandard transactions directly to miners and that it is arbitrarily tight, a relic of a time when there were no technical reasons to expand the standard OP_RETURN data limit. A common engineering principle in Bitcoin is to expand the types of standard transactions to be similar to consensus valid transactions. For the existence of arbitrary data such as JPEGs, the fee market should eventually price out these transactions as Bitcoin gets more use and fees go up.
When users cannot get their consensus-valid but nonstandard transaction into blocks by sending them through the network of Bitcoin nodes, they will hand those transactions directly to miners. This has several effects:
- It “encourages the establishment of direct miner submission which can undermine the permissionless nature of bitcoin and in particular again shifts profits towards larger miners,” argues Brink Executive Director Mike Schmidt.
- It harms the latency of block propagation. A node that doesn’t see a transaction has to do extra communication when that transaction is included in a block, which is undesirable
- It harms a noderunner’s ability to reliably estimate the fee rate to get a transaction into a block in a timely manner. When nodes do not see all of the transactions, they cannot accurately predict what the average fee rate is. Accurate fee estimation is generally considered a requirement for users to participate in the Bitcoin network.
Longtime Bitcoin Developer Greg Maxwell has been chiming in on the matter.
“The existent rule is entirely ineffectual: Parties current [sic] bypass these rules with other transaction forms (such as very harmful address stuffing which is impossible to block) or by direct miner submission, which will continue considering the millions of dollars miners have received mining transactions with violate the relay rules. Because of this it will not become effectual with time or tweaking. It is a dead parrot^policy [sic]. This is no surprise, since it’s a product of Bitcoin’s anti-censorship properties that generally filtering will not work except on the fringes. As such there isn’t practical upside to keeping filtering beyond what miners currently perform.
Poinsot, who inadvertently kicked this whole thing off, has a blog post on the topic.
Moving to Bitcoin Knots?
What began as a slow burn post-Ordinals has now started spreading rapidly among the anti-Bitcoin Core, pro-Filter crowd. Bitcoin Knots is a fork of Bitcoin Core maintained by Luke Dashjr that takes an opinionated view on Bitcoin by including certain rules, like not relaying Inscriptions. Knots still confirms Bitcoin blocks with JPEGs and actually relays almost all Runes transactions.
Knots has become a rallying cry for the Bitcoiners who want to prevent certain types of arbitrary data on Bitcoin. Its sole maintainer, Dashjr, is the leading voice against the rise in Ordinals and is increasingly at odds with Bitcoin Core Contributors.
Knots only comprised about 0.3% of the network in January 2023. Now it is 4.3% of reachable nodes and continuing to grow.
Conflict-of-Interest accusations
Prominent Bitcoin developer Jameson Lopp has been accused of a conflict of interest regarding his comments on the pull request. Lopp is an angel investor in Citrea, the company whose rollup – a type of layer 2 technology – design initially prompted the discussion on relay policy. When Lopp gave his support for Todd’s pull request, multiple parties called him out for “undisclosed conflict of interest.” However, Lopp discloses his investments, including Citrea, on his personal website. This spawned many conspiracies about the financial motivations of Bitcoin Core contributors and “spammers.”
It is important to note that Citrea did not request this pull request nor does it claim to benefit from it. In fact, it is questionable whether they would even take advantage of these changes to relay policy. Detractors such as Bitcoin Mechanic repeatedly make claims to the contrary.
My take on the OP_RETURN debate
A minor criticism that I consider valid is the removal of the startup option for the user to configure data carrier and data carrier size. I think Core should prioritize user ability to make any decision they please even if there are optimal default settings. There is even some discussion we could have on the Segwit data discount and reducing Bitcoin’s block size limit, although I think those are unproductive and likely bad decisions (but might be worthwhile nonetheless).
Other than that, I believe that the majority of the filter camp, especially the leading voices such as BitcoinMechanic, Luke Dashjr, and Jason Hughes are making wildly false claims and accusations. If you have read or listened to my statements on the topic and the filter camp you can tell that I am not a neutral figure. I feel very strongly about communicating accurately about technical issues and I believe that these voices represent at best misguided attempts to make Bitcoin morally pure at the great risk of reducing its censorship resistance.
It is very difficult to define arbitrary data from financial data, if there even is such a difference. Bitcoin is designed in a way that limits toxic arbitrary data by making it difficult and expensive to include such data in a way that outprices monetary use of the network. For example, users can store JPEGs onchain anyway, not just as Inscriptions. You can encode arbitrary data in innumerable ways, and attempts to play whack-a-mole to stop all of them will increase Bitcoin’s complexity and threaten increased censorship.
Claims that transaction volumes are down or that people aren’t running nodes because of JPEGs is laughable. As a simple heuristic, people making those claims should have all of their statements on this topic questioned as they are simply not operating in reality – you only need to look at the sluggish activity in the Inscriptions market to see why.
