By Aaron van Wirdum
Originally published on October 6, 2025. On October 10, Bitcoin Core version 30.0 was released.
A default setting in the upcoming Bitcoin Core software release, "Bitcoin Core 30.0," has divided the Bitcoin community. Some users have declared they will not upgrade to the new version (even though Bitcoin Core is the most widely used Bitcoin client) and will instead use Bitcoin Knots, a fork of Bitcoin Core maintained by Luke Dashjr, CTO of the Ocean Mining Pool and a vocal critic of the changes being made to Bitcoin Core.
The debate, rife with technical discussion, revolved around a seemingly trivial issue. Transactions with OP_RETURN outputs embed unbounded data (such as text or images) in a special way. Compared to previous versions, Bitcoin Core 30.0 will allow transactions with larger OP_RETURN outputs to enter the local mempool and forward them (on the peer-to-peer network) by default. This seems like a minor change, as Bitcoin Core (and Bitcoin Knots) nodes already accept such transactions as long as they make it into a block; they also forward transactions that embed unbounded data in other ways.
Still, the update proved divisive because it reflected deeper concerns.
Bitcoin Knots Viewpoint
Bitcoin Knots supporters generally dislike transactions that carry unrestricted data, often referring to them as "spam." By now, most have grudgingly accepted this as an unfortunate side effect of the Bitcoin protocol. However, they still believe this type of usage should be discouraged.
When Bitcoin Core developers implemented a limit on the size of OP_RETURN outputs in transactions forwarded by the software by default, it seems to have led to a shift in adoption of this practice in cryptocurrencies other than Bitcoin. (Most notably, this practice is often used to explain the "original purpose" of cryptocurrencies like Ethereum.)
In the eyes of Bitcoin Knots supporters, the new forwarding strategy of Bitcoin Core 30.0 symbolizes surrender - it is a signal to welcome "junk traders" back to Bitcoin.
One concern is that this new forwarding strategy will make it more attractive to users and projects that use unrestricted data. Because Bitcoin's block space is limited, using it to store unrestricted data will quickly fill up the blocks, which in turn will drive up transaction fees, even to the point where many regular transactions ("money transactions") are squeezed out.
Another concern is that while other methods can be used to embed unrestricted data, OP_RUTURN makes it easier to decipher than other methods; it requires less effort to convert it into, for example, an image. Bitcoin Knots supporters worry that this also increases the risk of illegal audiovisual material (such as child sexual abuse films) being included in blocks, potentially exposing node operators to regulatory pressure.
If the problem is that Bitcoin Core developers aren't resisting, then Bitcoin Knots represents that resistance. Even if they can't prevent unauthorized data from being included in the Bitcoin blockchain, or even prevent it entirely, they're at least not opening an additional door for it. In essence, they're sending a signal that this kind of garbage isn't welcome—a signal they hope will have a disincentive effect.
Assuming the disincentives succeed in keeping these junk traders out, Bitcoin Knots supporters say, Bitcoin can continue to be used for its original intended purpose: currency transactions.
Bitcoin Core Perspective
People use various methods to store unrestricted data on the Bitcoin blockchain. In fact, in recent years, many people have used " Inscriptions " to store images, and even embed unrestricted data using public or private keys .
Most Bitcoin Core developers agree with the Bitcoin Knots proponents on this matter: none of these uses are good, nor are they what Bitcoin was designed to do. However, of all these options, using OP_RETURN is the least harmful version, as it minimizes the amount of computing resources a node consumes, keeping nodes as cheap and affordable as possible.
Therefore, Bitcoin Core developers concluded that rather than trying to resist the use of OP_RETURN, it would be better to relax its restrictions; maintaining the restrictions would probably only make things worse, or even much worse.
One reason is that simply refusing to forward transactions with large OP_RETURN outputs doesn't technically have much of an effect. These transactions could still be forwarded to miners by other nodes (such as Libre Relay nodes) or sent directly to miners for inclusion in Bitcoin blocks. This approach could have a centralizing effect, as it's hypothesized that direct submissions would be more likely to go directly to larger miners, thereby earning additional fees, while smaller miners wouldn't. (If such transactions are included in blocks anyway, this direct submission approach could also inadvertently harm the nodes themselves.)
A more reliable solution—and arguably the next logical step—would be to invalidate (large) OP_RETURN transactions through a consensus protocol upgrade (a soft fork), effectively preventing them from entering blocks altogether. However, as mentioned earlier, people might use other, potentially more compromised, methods to store data on the blockchain. (In fact, many people already prefer Inscriptons because they're much cheaper than OP_RETURN for larger data objects (like images).
In theory, some of these methods could be curbed. However, most Bitcoin Core developers foresee that this would simply lead to a game of whack-a-mole, with spammers employing a different method each time. This would incentivize them to disguise their non-binding data as regular transactions, potentially leading to a situation where monetary transactions and non-binding data become increasingly indistinguishable.
The only remaining solution, therefore, might be to designate some person or group to arbitrate which transactions are acceptable and which are not, effectively introducing some entity with the power to censor transactions. Bitcoin Core developers (themselves an amorphous group of contributors) have no interest in playing such a role—not only because they don't want to become a target for regulators (and potentially be forced to abuse their power) but also because they want to avoid that path for Bitcoin.
Instead, they generally expect the problem to resolve itself without their intervention.
This is because monetary transactions are (relatively) very small. A single Bitcoin block can hold thousands of them. Other types of data, however, are typically much larger: a single image can fill an entire block. This means that a single "junk transaction" must outcompete many regular transactions (to provide miners with more transaction fees). Given sufficient demand for monetary transactions, using the Bitcoin blockchain to store data quickly becomes prohibitively expensive. In this scenario, non-limited data is squeezed out and disappears.
The vast majority of Bitcoin Core developers agree that Bitcoin should be a network used primarily for monetary transactions — not because they actively discourage other uses, but because that’s how the incentives of the system are shaped.
So what do you say?
Everyone is free to use whatever software they want, whether it's Bitcoin Core 30.0 (using this default setting, or turning it off), an older version of Bitcoin Core, Bitcoin Knots, Libre Relay, or something else. In this sense, Bitcoin users are truly autonomous.
Judging by sentiment on social media platforms like X, it seems a significant percentage of users will not upgrade to Bitcoin Core 30.0 or will switch to Bitcoin Knots. However, it's impossible to determine exactly what percentage of Bitcoin users these users represent. It could be a significant portion... or just a small (but vocal) minority.
Regardless, Bitcoin doesn't operate like a democracy. Because each node typically relays transactions to many other nodes, even if a small percentage of users choose to run Bitcoin Core 30.0 (or Libre Relay or a similar client), large OP_RETURN transactions are effectively free to propagate. This might not be completely prevented, but if Bitcoin Knots supporters want at least some disincentive effect, they'll need to convince a supermajority of node operators (perhaps 95% or more) to opt in to their filtering scheme.
If they fail to do so, then running Bitcoin Knots could be seen as an expression of dissent — just without the practical effect.
(over)
