A new default setting in the upcoming Bitcoin Core release, Bitcoin Core 30.0, has caused a rift through segments of the Bitcoin community. Some users have indicated they won’t upgrade to the new release of Bitcoin’s most-used client, or switched to running Bitcoin Knots: a software fork of Bitcoin Core maintained by OCEAN CTO Luke Dashjr, a vocal critic of the change.
The debate is quite technical, about a seemingly minor issue. Bitcoin Core 30.0 will start to relay transactions across the network with bigger OP_RETURN outputs: transactions that embed arbitrary data (like text or images) in a specific way. This appears to be a minor change because Bitcoin Core (and Bitcoin Knots) nodes do already accept these transactions once they’re included in a block, while they also relay transactions that store arbitrary data in other ways.
But the update has caused a rift because it reflects deeper concerns.
The “Bitcoin Knots perspective”
Bitcoin Knots proponents generally dislike that transactions can contain arbitrary data, or as they usually call it, “spam”. But so far, most have begrudgingly accepted this as an unfortunate side effect of the Bitcoin protocol.
They do believe this type of usage should be discouraged, however. When Bitcoin Core developers did this in the past by imposing a limit on the size of OP_RETURN outputs that nodes relayed, it indeed appeared to make some people decide to take these kinds of use cases to other cryptocurrencies instead of Bitcoin. (Most notably, this is commonly explained as the “origin story” of Ethereum.)
The updated relay policy in Bitcoin Core 30.0 in their view symbolizes the end of such resistance. It signals to “spammers” that they are welcome on Bitcoin.
One concern is that this will increasingly draw in this class of users and projects. And because Bitcoin block space is limited, using it for data storage will fill blocks up quickly, in turn driving up transaction fees, perhaps to the point where many regular (“monetary”) transactions are priced out because of it.
Another concern is that, even though arbitrary data can already be embedded in different ways, OP_RETURN makes it a bit easier to parse this data compared to other methods; it takes a little less effort to turn it into (say) an image. This, Bitcoin Knots proponents worry, also increases the risk that inclusion of illicit materials like CSAM (child sexual abuse material) could result in regulatory pressure on node operators.
If the problem is that Bitcoin Core developers are not resisting the spammers, Bitcoin Knots represents this resistance. Even if they can’t prevent arbitrary data from being included in the Bitcoin blockchain, or not prevent it completely, they at least won’t help open up an additional avenue for it. In effect, they’d be signaling that spam is not welcome, which they hope will have a discouraging effect.
Assuming this discouraging effect succeeds in keeping the spammers at bay, Bitcoin Knots proponents say, Bitcoin can continue to be used for what it was originally intended: monetary transactions.
The “Bitcoin Core perspective”
People can store arbitrary data on Bitcoin’s blockchain in various ways. Indeed, in recent years many people stored images in Inscriptions, and it could even be embedded in public or private keys.
Most Bitcoin Core developers do agree with Bitcoin Knots proponents that none of this is great, and it’s not what Bitcoin is intended for. But out of all these options, using OP_RETURN is the least harmful method, because it minimizes a computer’s resource consumption, thus keeping nodes as affordable and accessible as possible.
As such, Bitcoin Core developers figure that rather than trying to resist the use of OP_RETURN, it’s better to just allow it; limiting probably only makes matters worse, and possibly much worse.
For one, just refusing to relay these transactions technically doesn’t achieve much. These same transactions could still be relayed by some other nodes, like Libre Relay nodes, or they can be submitted to miners directly to be included in blocks. This in turn could have a centralizing effect, as direct submission would presumably be done to larger miners disproportionately, who then benefit from the extra fee revenue at the expense of smaller miners. (There are also some nuanced detriments for nodes themselves if such transactions do make it into a block anyways.)
The more robust solution — and arguably the logical next step — is to render (big) OP_RETURN transactions invalid through a consensus protocol upgrade (soft fork), so they can’t get mined at all. But the problem with that, as already noted, is that people might use other, more harmful methods to store data on the blockchain. (In fact, many already prefer to use Inscriptions because this is significantly cheaper for bigger chunks of data like images.)
In theory, some of these methods could be blocked as well. But most Bitcoin Core developers foresee that this will only lead to a game of whack-a-mole, with “spammers” resorting to different methods each time. It would incentivize them to “disguise” their data like regular transactions, which could lead to a situation where monetary transactions and arbitrary data become increasingly indistinguishable from each other.
The only solution left in this stage might be to designate some person or group to make judgement calls about which transactions are acceptable and which are not, in effect introducing some kind of entity that has the power to impose censorship. Bitcoin Core developers (themselves a rather amorphous group of contributors) have no interest in taking on such a role — not least because they don’t wish to become a target for regulators that could force them to abuse this power — and prefer Bitcoin not to go down this path at all.
Instead, they generally expect that the problem will resolve itself over time, without their interference.
This is because a monetary transaction is relatively speaking a tiny bit of data. A single Bitcoin block can fit thousands of them. Other types of data tend to be much larger; just one image can fill up an entire block. This means that a single “spammer” typically has to outbid many regular users. Given enough demand for monetary transactions, using Bitcoin for data storage quickly becomes expensive. Arbitrary data should in this scenario be priced out and disappear organically.
Most Bitcoin Core developers agree that Bitcoin should be a network primarily for monetary transactions— but not because they’ll actively resist other use cases, rather because this is how the incentives of the system already align.
So now what?
Everyone is free to use whatever software they want, whether this is Bitcoin Core 30.0 (with or without touching this default setting), an older version of Bitcoin Core, Bitcoin Knots, Libre Relay, or anything else. In this sense Bitcoin users are, in a very real way, sovereign.
Judging by sentiments on social media platforms like X, it does seem that some non-trivial segment of users won’t upgrade to Bitcoin Core 30.0, or indeed switch to Bitcoin Knots. But it’s impossible to tell how big of a share of Bitcoin’s user base this really represents. It could be a large majority… or it could be a small (and loud) minority.
Either way, Bitcoin does not operate like a democracy. Because every node typically relays transactions to multiple others, if even a relatively small minority of users choose to run Bitcoin Core 30.0 (or Libre Relay or something similar), larger OP_RETURNs should in fact propagate rather freely. This probably can’t be stopped completely, but assuming Bitcoin Knots proponents want to at least meaningfully stifle this, they’ll need to convince some supermajority of node operators (perhaps 95% or more) to join them in their filtering efforts.
If they fail to do that, running Bitcoin Knots can be seen as a voice of dissent— but one with little practical effect.
Aaron van Wirdum is the former Editor-in-Chief of Bitcoin Magazine and author of The Genesis Book: The Story of the People and Projects That Inspired Bitcoin. Follow him on Nostr.