Red Vs. Blue: The Bitcoin Ordinals Wargame

For over a year, some have considered bitcoin to be under siege. Fee spikes and transaction volumes associated with Ordinals and Inscriptions have impacted other users, and some even propose these may be cover for a deliberate attack by a well-funded state actor. Yet at the same time, others see the very same events as demonstrating Bitcoin is stronger than ever. Tensions between both sides are escalating, positions are becoming entrenched, and dialogue is breaking down. Battle lines are being drawn and reconciliation seems increasingly unlikely. We may be in the early innings of the next fork war, and I believe that once again, one side is fundamentally misunderstanding the issues.

Fascinatingly, the debate is almost identical to one from 2014. Bitmex’s excellent article describes the players and moves of that time, and the ultimate outcome. You may or may not wish to read up on your history first; at the end of the piece, we will tie this current debate back to the events of 2014.

With the aim of presenting a neutral perspective, the conflict can be described as whether Bitcoin as a system should change to prevent certain kinds of transactions. What is undeniable is that these transactions are currently being made, they do not presently invalidate blocks if included, in the majority of cases are competing for block space with fee bids just like every other transaction does, and collectively spending a significant amount on those fees.

Some people feel these transactions are directly harmful to the network from a combination of their technical nature and the popularity of their usage, and through this harm they reduce Bitcoin’s ability to be good money. Others believe differently: either making use of these transaction styles themselves - or are ambivalent, but feel the perception of harm is overblown, and the cure would be worse than the disease.

For shorthand and neutrality I will simply refer to those who wish to stop these kinds of transactions as Blue Team, and those who prefer to keep the status quo as Red Team. For the purposes of discussion it does not matter the reasons behind the motivations of either side, only that they are motivated, and act to further these high-level goals. This article will lay out a realistic play-by-play for the future of this conflict, based on those goals for each faction, and explaining the technical possibilities open at each step. It will strive to remain clinical and discuss only the mechanics, leaving out elements that have subjective interpretations. You can form your own opinions in areas concerning subjective worth and values.

Background (useful? Omit? Link another article instead?)

Some background: In early 2023, developer Casey Rodarmor published his Ordinals and Inscriptions protocols, which are rulesets for alternative interpretations of data in the blockchain. This has led to increased usage of blockspace by people engaging in these protocols, which drive up fees - most notably enormous spikes in May and December. Since these are arguably not using bitcoin as money but for other purposes, some voices advocate that this usage ought to be stopped and argue this degrades bitcoin’s usefulness as money. It’s important to understand technically what is going on with these protocols, so that a reasoned debate can be had on whether this is possible or even desirable.

Ordinals are simply an accounting method by which to view regular bitcoin transactions. This lens allows “tracking” individual satoshis as they move through the network, by which some might be seen to have more value than others - for example, satoshis that were once handled by Satoshi himself. This is a nonsensical fiction, detached from technical reality - satoshis are a measurement of quantity, and do not exist as individual items - it is like tracking a particular ounce of water in a river. But so is bitcoin itself a fiction: a particular interpretation of a particular dataset by a group of individuals, who subjectively value things using their common lens. Bitcoiners value bitcoin, even though it is all just 1s and 0s, whilst nocoiners laugh at their foolishness - bitcoins don’t exist! Ordinals enthusiasts value individual satoshis, even though it’s all just bitcoin transactions, whilst bitcoiners laugh - individual satoshis don’t exist!

Inscriptions are a technique to store additional non-monetary data in the blockchain, for example, image files. When used in combination with Ordinals, the result is much like a tradeable NFT as is popular on other chains. Bitcoin is not designed to support this usage, and it happens by exploiting its permissionless elements. When you create an address to receive bitcoin into, you are defining a lock that must be opened to spend the funds, and by extension also the key that is required to unlock it. The tactic used by Inscriptions can be thought of as designing the key to look like a cartoon character (the image, or whatever other arbitrary data the user wishes). Doing this is more costly than using a normal key and the user pays mining fees to do so, the same as every transaction.

Battle for the mempool

Since Red Team are happy with the status quo, the first move comes from Blue Team, who for some months in the community have been advocating “fix the filters”. This refers to expanding a set of rules applied by each node, by which it decides whether to forward a pending transaction in its mempool to its peers, or whether to discard it. Nodes each build their own local mempool selfishly, in order to speed up validating new blocks when they arrive, because the transactions it contains have already been checked ahead of time. They also altruistically relay transactions they know about to their connected peers upon request, to help each other toward that goal. Each node’s operator chooses their own mempool settings and is not obligated to set them in any particular way, by any direct or indirect means.

Filters to discard pending transactions from the node’s mempool already exist for many reasons, mainly to prevent its memory from being overwhelmed, but have also been used to add friction to the use of certain transaction types in the past, in the aim of dissuading their use. There is a great deal of confusion around what node filters actually do, and how they directly and indirectly affect different elements of the network.

The core idea in this case is that if enough nodes refuse to relay a pending transaction, it will fail to reach a miner and thus will not be included in a block. It’s important to note that these filters do not apply to transactions that are already mined in a block - the rules for rejecting a block are known as consensus, which is much more powerful, delicate and requires significant coordination to successfully change. We’ll return to consensus later.

“Fixing the filters” is unlikely to achieve Blue Team’s goal of preventing certain transactions for multiple reasons.

Firstly, bitcoin is designed to be robust against malicious nodes: since running a node is very low cost, it would be a fragile system if anyone could block your ability to transact just by spinning up countless nodes on a cloud server farm. Each node forwards every transaction it hears about (and considers valid) to all of its connected peers, meaning it quickly floods the network, and even a small minority of cooperative nodes is enough for every transaction to make its way to a miner. This was demonstrated again in practice recently by the “full-RBF” controversy in 2023, which you can learn more about here. In that case, the default node filters, already almost ubiquitous on the network, were discarding valid transactions that replaced (spent the same inputs as) another pending, lower fee transaction. If one of these replacements does reach a miner, it can be rationally expected it is mined rather than the lower paying version, since it is more profitable. Once only 10% of nodes modified their filters to relay these, instead of discarding, and it was seen that they were getting mined with over 95% reliability.

Thus, to achieve active suppression of valid transactions just using filters, adoption must be over 90% across the network. Considering less than 40% of nodes even run the latest version of Bitcoin Core, which was not contentious at all, this seems like a pipe dream. Even if the required 90%+ adoption were to be achieved, like curtains on a window, filters only directly impact the user’s own node. It is of course not possible for a third party to control what software or settings you run on your own computer, nor for them to control who you communicate with.

Blue Team largely concede that achieving meaningful change with just the node filters is unlikely, and hope to also use it as a means of social signalling. They purport that the Bitcoin Core software updating its standard filters shows Red Team that they are unwelcome and will be actively resisted, hoping they will think twice about responding, even if the rollout itself takes some time. Note that the most significant action here is simply the public inclusion of the filter update to Bitcoin Core: nobody is obliged to run the update, nor can anyone know beyond doubt which version other nodes are running, nor if those nodes even represent real users - the nodes you are connected to could have been spun up en masse on a cloud server at almost no cost.

They argue it also communicates the network’s serious wishes, in the hopes that miners take the hint and stop including the specific kinds of transactions in their blocks. To do so is voluntarily declining income - since these transactions are valid, and bidding well for block space, and their inclusion won’t get the block rejected by the network, at least today. Finally, if the miners are seen to not respect these wishes, Blue Team can confidently assume those miners are in fact hostile to Bitcoin, and feel justified in escalating their response.

It is worth noting that all the principles laid out so far are what also insulate all users from censorious governments, for example: if you can get your transaction to a miner by any means, and there is at least one miner somewhere in the world willing to mine it, you will be able to transact. In fact it is a valuable counterweight to the most powerful censors: the more they decline to include specific transactions, the more the fee pressure builds as the transactors’ desperation and internal competition increases. In a serious government-driven censorship campaign, we may even see unknown miners turning mothballed machines back on just to collect all the “black market” fees waiting on the sidelines.

Given the low likelihood of success, Red Team likely do not need to take any action and their transacting will be unaffected. But if any of the Blue moves did cause any even temporary light disruption, there are numerous small steps available to ensure transactions can reach miners even if some nodes on the network are uncooperative. Libre Relay exists, a tweaked version of Bitcoin Core with its filter policies loosened to more closely match consensus rules. Libre nodes prefer to connect with each other over normal Core nodes, and in doing so create a robust relay network that routes around obstructors. Running Libre instead of vanilla Bitcoin Core is a trivial change and a one-time decision. The Ordinals community is already discussing migrating to ensure they have no relay issues - though they currently don’t experience any.

But relaying transactions through the node network is only one means. The target is only to get your transaction to an active miner, which really is just delivering a piece of data. Thus it is predictable that alternative delivery methods would be utilised for those unwilling or unable to use the relay network - and be polished into services that can command a premium from those who wish to use them. Mining of even already-filtered transactions through “out-of-band” means has happened throughout history, but was definitively demonstrated by the Taproot Wizard oversize transaction in February 2023, the miner of which was paid externally (unlike regular transitions). Then, to make a point in a debate, the ”Consensus is King” transaction in January 2024 created dust - a 21 sat UTXO, too low in value to cover the fees required to ever spend it again, a behaviour that is currently filtered by all existing nodes. That transactions’ fees were paid in-band like any other transaction, and it was sent over a Twitter private message - never once being shown to the node network. This direction was then productized by Marathon pool’s new Slipstream service in March, which provides a simple web form to paste a transaction to be fed directly into their own node, and will be mined as long as it is consensus-valid and pays a premium over market rate. It is logical to assume from here that other pools will join to compete for the extra fees these transactions can offer, should they ever even be successfully blocked at the node level, and it is trivial for users to take advantage of them.

Consensus Warfare

Let’s move now into speculating on the future, assuming that Red Team are happy running Libre nodes or using miner APIs, and at least some miners have continued to accept their fee bids, instead of altruistically declining them. How might Blue Team respond to their continuing presence in blocks? Who knows how much time elapses first, but if the desire still exists to rid bitcoin of these certain types of transactions permanently, ultimately the next escalation is a fork to enforce excluding them from blocks.

Changing your node’s consensus rules can see you rejecting some blocks as invalid whilst the rest of the world does not, meaning your local copy of the blockchain does not match everyone else’s. You now exist on a fork split off from the original chain: new blocks mined on the original chain are incompatible with yours, so your node discards them. Anyone else that made the same change at the same time is on the same fork with you. Upgrades to Bitcoin are made by coordinating forks: everyone agreeing to change their rules in the same way at a fixed future time. They are serious undertakings involving a great deal of organisation to make sure nobody gets left behind. The history of Bitcoin fork activations is outlined in detail here, including their problems, and is an illuminating read.

The blockchain is progressed by miners expending real-world energy to build new blocks: that’s the unforgeable cost proof-of-work which is what makes Bitcoin secure and valuable. Work cannot be applied to more than one block at a time: they must decide whether to build on the original chain, or the new fork. Builders of new blocks have permission to issue themselves a fixed amount of new coins within it as a reward, which of course is only reflected on the side of the fork the block is in. If they do not properly enforce the new rules within their blocks on the new fork, the nodes will reject those blocks as invalid, and they will no longer receive the reward - though the energy they expended is gone regardless. Thus, users via their nodes are collectively able to force miners to judge which set of rules they think will be perceived as more valuable by the market. Nobody can control the decisions of others, but you can present them with new options for how to use their fixed resources, and stop “paying” them for their work if they make the “wrong” choice, in your eyes. It’s a complex dance of choices, incentives, and subjective value judgements that spans multiple parties with a variety of interests. Forks will always have a degree of uncertainty and so in Bitcoin they are rare and significant events.

The key to a prospective Blue Team fork is that the target transactions must be identified by some robust technique so that the block can be rejected, but without being overzealous and catching too many “real” transactions. There is a whole spectrum of heuristics that could be applied, individually over time, or many batched together in a group. It’s important to note that because these are consensus rules, every change must be extensively reviewed and communicated well ahead of time to give everyone a chance to opt-in, especially miners, who have the most to lose by getting something wrong.

For the purposes of discussion, let’s presume the fork is a bundle of new rules aiming for broad-spectrum coverage. These rules are on the aggressive side, but would not affect normal users at all, whilst forcibly preventing all current known protocols utilising Bitcoin which Blue Team consider to be parasitic. They are derived from suggestions by developers and conversations with people who currently use such protocols.

A block will be rejected if it contains a transaction that does not respect the following:

1. Mining fees must be less than the smallest output. This aligns with monetary use, since no rational actor would pay more to send money than they want the recipient to get.
2. OP_RETURNs, scripts, and taproot scripts may not be larger than X bytes. This limit was already enforced as a node filter but not at consensus level. As such it will not affect the vast majority of normal usage, which fit within this size anyway, but does reduce flexibility of Bitcoin’s smart contracting at the extremes of technical possibility. Note: the correct size to target in bytes can be debated; what matters here is the principle of some hard cap.
3. Taproot scripts may not have provably non-executable segments, such as starting with OP_FALSE OP_IF. Any code following this can never be run, since the instructions are to immediately exit and discard everything after, and so is just excess data with no legitimate use. The techniques in use will need to be identified and specifically banned.
4. All keys must be verifiably on the ECDSA curve. Since a key that is not on the curve can never successfully sign a transaction, there is no legitimate use for them.

Time estimates for Blue Team to implement this suite of changes could be 12 months at an unrealistic bare minimum, but more likely multiple years. This is based on historic forks, the pace of development in recent years, the scope of the changes, and controversy around them.

In responding to this move, Red Team can take advantage of the fact that Bitcoin development is necessarily in the open, and work on their counter whilst the fork proposal rumbles slowly toward activation. They do not need to publicise it in advance and can deploy it at any time, but would be wisest to wait until after the fork activates, since that would result in the longest possible response time from Blue. Since the Red Team protocols and networks are young and highly engaged, they can reach their internal form of consensus quickly, and do not have large vested interests like miners, who must negotiate with factors like geopolitics and energy grids.

The users aligned with Red Team are much less conservative than Blue Team, quickly adopt new technology, enjoy overcoming challenges, and have less interest in building for the long term. They collectively have significant capital they’re willing to spend, and seem to also enjoy annoying Bitcoiners. History showed adoption speeds for the Ordinals and Inscriptions protocols of around four months, and that was into a market that was not paying attention to Bitcoin as a possible source of new innovations or gambling opportunities.

Techniques to bypass the new consensus rules include:

1. Inventing new ways to create non-executable Taproot script segments, which ultimately only entails generating a “0” by any means the designer can dream up. The Bitcoin code interprets this as an exit command like OP_FALSE, and anything following the 0 is not run to save on computing, since this function has already failed. But there are also many legitimate reasons for a script to generate a zero at some point, and in some cases is vital to function.
2. Defining ways to signal across multiple size-capped scripts that they should be interpreted together as one large item, bypassing the caps. This can similarly be accomplished an enormous number of ways, since the metaprotocol is flexible and aware of Bitcoin, whilst Bitcoin is very rigid and can only reference metaprotocols manually and extremely rarely.

It seems an entirely reasonable assumption that Red Team would monitor public development of attempts to block their transactions, design in parallel the techniques to bypass them, launch them to the market soon after they become mandatory, and within weeks or months return to a similar level of usage to before.

It is possible that the network simply never adopts or activates the Blue Team fork in the first place. However, it seems a suite of changes like this would be appealing to enough people, with few enough apparent drawbacks, that it has a reasonable chance.

Nuclear Escalation

With Red Team having proven they are immune to filters, and willing and able to devise workarounds to even consensus rules blocking specific techniques, if Blue Team wishes to continue the brush must get significantly broader. At this point they face some difficult decisions and must make real sacrifices.

The first question is whether there is sufficient will to respond at all: the war will have been raging for many years, their last move was a serious one over a year in the making, and may have been thoroughly neutered in a small fraction of that time. Though average users would not notice, Bitcoin’s technical flexibility has been reduced - yet this sacrificial lamb still failed to rid them of Red Team, and next steps only follow this path further. Let’s imagine that they do proceed, and a second, extremely robust fork is proposed.

When blacklists don’t work, the only alternative is whitelisting, as previously considered. In practice this means only a fixed set of script designs are to be permitted in blocks, designed to cover all common use cases, such that average users will be unaffected.

This stage may also see banning of OP_RETURN altogether if there has been excessive usage by external protocols deemed parasitic. Such protocols have already been designed today, with more on the way, but not yet been launched into the market. OP_RETURN serves no purpose except to carry arbitrary data, but is seen as relatively benign and has found usage for things Blue Team consider acceptable or even desire, like privacy-enhancing tools and timestamping (which has even been used to validate a national election). However, the amount of data needed to facilitate subjectively good things is also enough for subjectively bad things, multiples more in fact - effective timestamps need a lot of space, whilst simple messages do not. And if history is any guide, Red Team’s usage frequency of these features may outweigh Blue Team’s usage by several orders of magnitude.

Together these changes close off not just the mechanisms that have historically been used by Red Team, but remove the design spaces altogether. The tradeoffs to make these small changes are significant. With whitelisted scripts, possibilities for innovations or simply bespoke designs to suit unusual custody requirements are severely hampered. Any new script would require further forks again, inciting the detailed and lengthy scrutiny of the developer community, rather than being up to the individual actually using it.

Less obvious a tradeoff is the encroaching centralisation. The whitelist approach is naturally centralising: before you can use a script you now need the opt-in consent of the network, which is difficult to organise, with countless users and many conflicting interests. Social structures organically self-assemble, and individuals tend to choose to outsource complex judgements or service provisions to trusted sources, leaders and cultural figureheads to some degree. If there was a rapid neutralisation of the last fork by Red Team, there may also be a sense of urgency - or simple bruised egos in the driving seat. All of these factors trend toward an increasing dependence on central bodies for expedience, and complacency gradually builds, which erodes Bitcoin’s resilience to sophisticated social attacks.

If Red Team responds to the closing of the script and OP_RETURN design spaces, the next logical move would be turning their attention to other free-entry transaction fields: addresses and amounts. An address is just a string of characters, and characters can be used to convey data. The first fork required that all keys be verifiable, which makes it more difficult to “grind” out a solution, but it’s still fundamentally just a computing task: find a valid address string that also contains your desired data.

Amounts are similar: they’re just a number, with no restriction on what that number is, except that the sender has permission and sufficient capital. One unique element of this field is that using more digits requires more capital - but the protocol should be designed such that the data-satoshis can be a self-send, and any ownership is handled by another output. This is already how OP_RETURN based protocols are designed. Similar to before, protocols could be defined for instructing that multiple fields are interpreted together as one.

Important to note is that protocols to leverage addresses and amounts to carry data are already in development in 2024, and have existed in primitive form for over a decade. Adoption is limited as other methods are easier and more efficient.

Mutually Assured Destruction

Should Blue Team still wish to continue, the only remaining move is to apply whitelisting to the address and amount fields. Though extremely unlikely to ever happen, let’s explore that world as a thought experiment.

Whitelisting amounts may not be as dire as initially appears - most people are familiar with fixed-denomination bills and coins in fiat currencies. Though it’s much less efficient to use Bitcoin this way, reducing net throughput since each transaction uses multiples more inputs and outputs, it could be made to work.

Whitelisting addresses seems unavoidably to create a Bitcoin completely captured by corporate interests. There is not to my knowledge any system design that is permissionless enough for anyone to register an address which couldn’t still be exploited by Red Team. Thus it must be permissioned, which centralises Bitcoin to the point of absurdity, where transactions can only be between established players such as large businesses and other vested interests. The resulting system becomes something like a publicly-auditable Fedwire or SWIFT, with fixed supply: though still better than the world we have today, it’s a shadow of what Bitcoin could have been. With little sovereignty over their own money, very few parties outside these whitelisted entities will have any reason to run a node, which opens the door to collusion and protocol changes. With the population at large having no direct voice in the system, there is little ability to hold misbehaviour to account, and eventually short-term profit incentives dictate the institutions will replicate the gold and fiat eras by debasing the supply.

A brighter future: closing thoughts

The primary objection of Blue Team to these transactions is that they are seeing significant usage but are often not using bitcoin as a monetary asset. Instead they are using it as a substrate for gambling, in a way that uses more of the limited block space than a monetary transaction would. It’s unfortunate that at times gambling has more demand than digital permissionless sound money, sometimes much more, and the hope of winning often has the gamblers willing to spend much more on fees than monetary users, making it uneconomical for many people to use Bitcoin how it is intended and built to be used - as money. In the long run, gamblers don’t need Bitcoin’s unique traits and costly decentralisation, and they’re usually content with centralised platforms or pseudo-decentralisation of other chains. If gambler dominance of block space were to be prolonged, the expense of using it would raise the minimum wealth floor of who can justify using it, unfortunately locking out the people that need it most.

It’s difficult to argue with most of the above, but Blue Team have approached the problem from the wrong direction, one which gradually hampers and centralises Bitcoin until such time that Red Team decide to voluntarily leave, if ever. As we have discussed, Red Team have a much easier time adapting to Blue Team’s moves than the reverse. It also ignores a key fact: that a congested chain is the expected future anyway - in fact, it’s mandatory for Bitcoin’s survival as the block subsidy falls away, halving by halving.

The only logical solution is we need to improve efficiency of block space usage by increasing the economic density of transactions, and in the process, move more and more of the actual transacting off-chain. We’ve always known we had to do this, we just thought we had more time. In the off-chain world, waves of fees and other shenanigans affect monetary users increasingly rarely.

As a global-scale censorship resistant permissionless database, throughput is naturally limited by technology and even physics. Lightning works very well, but only shares a UTXO between 2 people at a time, and in current form can require surprisingly frequent usage of the chain to resolve issues or shuffle liquidity, so it still can’t scale far without sacrificing sovereignty. If sovereign usage is not available to as many people as possible, Bitcoin is not realising its fullest potential.

If multiple users could share a UTXO, they can combine forces like a school of fish and hold their own against even gigantic whales. If the Bitcoin network were to activate one of the covenants proposals, many new possibilities open up for collaboration without sacrificing sovereignty. It’s not perfect, and there is so much work still to be done. But the foundations are rock solid, safety concerns have been satisfied, the scope of what they can improve is amazingly broad, and the journey to activation is long. We’re too late for this adoption cycle, but we could still be ready for the next one.

Let’s move past the current distractions and build for the future, together.

Analysis of script sizes:

https://medium.com/coinmonks/on-bitcoin-transaction-sizes-97e31bc9d816

This is a guest post by Owen Kemeys. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.