Opportunities emerge from crises. Although it may sound like a self-help phrase to see the glass half full instead of half empty, in a world facing a crisis of opportunity, Bitcoin offers us the opportunity to do things better and better.
A crisis is a break in the continuum of normality. A sudden event interrupts the normal flow of events and demands reflection in order to decide how to proceed. It is no coincidence that crisis, criterion, and criticism share a common etymological root. A crisis demands the development of a criterion in order to make the most accurate critique of events.
I have already discussed this idea, suggesting that Bitcoin is the crisis of the legacy financial system. But within Bitcoin's history, crises have also been regular, to the point that some have even been called wars. We have the so-called Block Size Wars, the debate over scalability that led to the BCash fork and, similar to the ten-year Trojan War, this year has seen a renewal of the conflict that began in 2014, known as the OP_RETURN Wars.
The plural is intentional in Wars because it has been a conflict that has arisen on more than one occasion. It makes sense, given that it's an essentialist but also ethical conflict, to discuss the nature of this cryptic Being we call Bitcoin, and, even more so, what Bitcoin should be.
It's inevitable that the debate over the essence of Bitcoin will be a constant. As an open, neutral, and leaderless network, there is no central figure who determines once and for all what Bitcoin is and should be. Only the consensus rules and consensus on the rules offer guidance. We have the supply cap, the block space cap, proof of work, and the largest accumulated work; all rules that are immutable unless a hard fork is made. However, permissum videtur id omne quod non prohibitur; everything that is not prohibited is permitted... or not?
Aside from consensus rules, there is another subset of protocols, known as standard rules, that each Bitcoin client or software implementation (such as Bitcoin Core) applies to decide which transactions they consider “standard” and therefore relay or include in their mempool. Among these standard rules is the OP_RETURN limit.
The 80-byte limit for OP_RETURN was established in 2014 in Bitcoin Core to prevent non-monetary transactions from clogging the network and increasing the weight of Bitcoin's ledger, thereby increasing the storage costs of running a Bitcoin node. It was a sort of deterrent, acknowledging that some users considered Bitcoin, apart from being a monetary network, to be the most robust decentralized database in history, but at the same time, it limited the amount of data that could be recorded through Bitcoin Core on the network.
Removing this limit has been the source of a fierce debate within the Bitcoin community or at least within a seemingly minor segment of it. It's interesting to note that, years ago, a debate like this would have scared investors, leading them to reduce their BTC positions out of caution. The fact that the price is now rallying above $100,000 suggests that most current Bitcoin holders are likely unaware of the ongoing war.
This reveals a certain culture of trust among Bitcoin software maintainers or rather, a culture of indifference to fundamental issues other than price which could be dangerous in the long run for maintaining strict network governance. That's why it's valuable that, at least in part of the community, there remains conflict and accountability. The limit is being eliminated because human ingenuity has found ways to circumvent it. It sounds like a weak argument, like saying stealing would be legalized because it hasn't curbed theft. However, some developers argue that the limit does more harm than good.
Transactions with OP_RETURN are non-spendable. This means that while they can increase the weight of the Bitcoin ledger, they do not clog the UTXO Set. The UTXO Set is the set of valid transactions that can be spent on the Bitcoin network. This is stored on each node to validate new transactions, verifying that the entries reference valid UTXOs and thus avoiding double-spending, and optimizing verification, since it is not necessary to traverse the entire ledger to validate a transaction. This last point brings us to an important nuance: a node can “prune” the ledger, but not the UTXO Set.
Alternatives to OP_RETURN, such as the use of the P2TR script, clog up the UTXO set. This was the reason why Casey Rodarmor, creator of Ordinals, discouraged the use of Inscriptions and promoted the use of Runes instead. But now, the Citrea ZK-Rollup is using the aforementioned script to implement its Clementine bridge.
This has reignited the battle, opening a new rift in the community, with one side arguing that the limit should not be removed because it promotes spammy, i.e., non-monetary, transactions; and other sides arguing that it creates more costs than benefits. But, from our perspective, what this debate teaches about Bitcoin is far more important than the debate itself.
Whether or not the cap is removed, interested parties can pay their favorite mining pool to record their non-cash transaction on the ledger, as Taproot Wizards and the Luxor pool did when they recorded the largest transaction ever (3.94MB) for an Ordinals registration, or as is done through services like Libre Relay and MARA Slipstream.
Clients and nodes can set policies to decide which transactions pass through their mempool, but once a transaction is added to the chain in a block, it will be part of the ledger forever. They can prune their ledger, but they cannot prune the UTXO set.
Hence, the true crux of this crisis is more political-philosophical than technical. Above all, because it confirms the adversarial nature of Bitcoin. Despite the fact that the integration request to remove the OP_RETURN limit has more votes against than in favor, the debate is still ongoing, and the likelihood that the main Bitcoin Core maintainers will move forward with the removal in the short term is low, many node operators have decided to migrate from Bitcoin Core to Bitcoin Knots.
Bitcoin Core continues to maintain over 90% dominance. Source: Coin.Dance
The way the integration request has been pushed has generated distrust among Bitcoiners. First, due to the way developer Peter Todd removed the optional limit for manual client configuration, as well as the allegations of censorship that arose when comments on GitHub were deleted. Then, due to conflicts of interest, such as Jameson Lopp's investments in Citrea. But finally, due to an ontological and ethical issue: what is Bitcoin and what should Bitcoin be?
Many of the people who have migrated to Knots have done so out of principle, even at the risk that Knots is maintained almost exclusively by arguably the biggest campaigner against non-cash transactions in Bitcoin, developer Luke Dashjr, while Core has dozens of developers reviewing the code. Beyond the technical aspects, there seems to be a disagreement over whether Core maintainers agree to give carte blanche to those who are said to be flooding the network with spam. They believe that this should not be what Bitcoin is, even though it may, in fact, be.
Therein lies the true importance of this debate. It reminds us that Bitcoin is constructed as a solution to the Byzantine Generals' Problem, where distrust of the other actors' true intentions is a prerequisite. Therefore, these crises reaffirm the importance of maintaining suspicion and high vigilance, because we don't know when developers can be bought off to capture Bitcoin, even more so in a context of the Bitcoinization of the State.
But above all, this debate is good for Bitcoin because it shows us that, in the face of crises and disputes, the best possible response is to decentralize further. The hegemony of Bitcoin Core as the only relevant client for so many years has become a single point of failure that should not be accepted at this point. Once again, in the face of a crisis, our critical eye is heightened, and, as is often the case, the final solution found is “let's decentralize further.”
The decision made will not change the essence of what Bitcoin is, namely, the consensus rules. Since this is a standard rule, each Bitcoin implementation or client can decide whether to enforce it or not. Just as the Bitcoin Knots implementation will apply all possible standards to reject these types of transactions, another developer can create a new client that, on the contrary, applies all possible facilities to promote the use of Bitcoin as a JPEG database. In the end, the market will decide what it truly values in Bitcoin, just as it has throughout its history.