You Cannot Stop Bitcoin Metaprotocols

Bitcoin Magazine

You Cannot Stop Bitcoin Metaprotocols

Bitcoin is a database. 

This is an inescapable technological reality. Money itself is simply a ledger, a record of who has what. Even physical cash is simply distributing that “database” in the real world. You no longer have to check against some central ledger to verify anything because the simple act of handing it to you is that process of verification. The “entries” in that ledger are passed around disconnected from some central record. Bitcoin is simply a digital database attempting to replicate the most important property of that physical one known as cash: not needing a database operator’s permission to spend your money. 

Imagine the futility of trying to stop people from defacing dollar bills. How many of you have stamped “Buy Bitcoin” onto fiat currency? Defacing a banknote in the United States is a federal crime. You can spend 6 months in jail for it. Does that stop anyone?

Do you seriously think that could be enforced anywhere? Do you remember Where Is George? People would stamp a website on dollar bills so people could enter serial numbers when they got them and track where cash notes were circulating geographically. 

Artists do innate murals and collages on cashnotes. You literally cannot stop it. 

Why is there a strain of magical thinking that believes this is possible simply because the database is digital? 

By its very nature Bitcoin requires supporting the inclusion of arbitrary data (read: data that it is impossible to know or define ahead of time) in order to allow users to transact. You don’t know ahead of time how much money you will send (the satoshi field in outputs), where you will send it (the script field), what blockheight you might wish to spend it at (the nLocktime field in a transaction, or the nSequence field in a transaction input). 

Without allowing for these pieces of arbitrary data, it is not possible for Bitcoin to exist as a system. 

Metaprotocols

A Bitcoin metaprotocol is a protocol layered on top of the base protocol, Bitcoin, that interprets the data and actions of the underlying protocol through the lens of additional rules that do not exist on that base protocol. 

A historical example of this would be the Counterparty (XCP) protocol. Using OP_RETURN, an opcode in Bitcoin script that simply pushes arbitrary data to the stack creating an unspendable output that can be ignored by the UTXO set, XCP embeds its own metaprotocol messages. 

These messages facilitate the issuance of new tokens, the transfer of tokens by defining how much is being sent and where, as well as other messages that enable on-chain trustless exchanges between XCP itself and any other tokens issued using the protocol. 

The Bitcoin protocol itself doesn’t understand, or care, about any of these messages. They are interpreted by extra software run on top of Bitcoin. It is completely possible for anyone using Bitcoin to craft totally invalid XCP messages and get them confirmed on-chain, but XCP software will not recognize it as valid. The person crafting these invalid messages is simply wasting their own money creating pointless transactions. 

Absolutely nothing can stop people from interpreting valid data on Bitcoin through the lens of extra rules external to the Bitcoin protocol in this manner. 

Ordinals function in a very similar way. Users assign a unique ‘serial number’ to every single satoshi that is mined, and have created their own accounting system to interpret the input and output ordering in a transaction to follow where “individual satoshis” are sent in the course of transacting. 

The Bitcoin protocol itself is completely unaware of this external protocol, and nothing at all can be done to stop users from interpreting valid Bitcoin transactions in this manner. Anyone can interpret the data published on the blockchain however they want, applying whatever additional constraints they choose that do not conflict with the base Bitcoin protocol rules. 

Nothing stops people from crafting invalid or malicious metaprotocol messages, and confirming those in the blockchain, but users running metaprotocol clients will simply ignore them as invalid. This is the key difference between the Bitcoin protocol itself, and metaprotocols. Bitcoin consensus rules prevent protocol invalid messages from ever being included in the blockchain, metaprotocols don’t (or rather can’t). 

Data Embedding

The difference between the two metaprotocols above is that one requires embedding extra data on-chain in order to function (XCP), and the other does not (Ordinals). So you might be assuming that you can simply prevent protocols that require embedding extra data by simply preventing that data from being embedded in the first place. 

While it is true that specific mechanisms of data embedding could be prevented by softforking that particular mechanism out of the protocol, i.e. rendering transactions that make use of that mechanism invalid, you cannot prevent data from being embedded in general. 

Take for instance the “Inscription envelope.” This is simply a specific method for guaranteeing that the data embedded in a spending witness is never actually executed. This is done by using OP_FALSE, which pushes a 0 (or False value that will fail verification) onto the stack before the OP_PUSHes that actually embed the data. This causes the script interpreter to simply skip verifying the data after the OP_FALSE. The key functionality required is putting a 0 on the stack. 

If you invalidate by consensus the use of this specific script format, there are other ways to put a 0 on the stack, or to ensure the script interpreter scripts the verification and execution of subsequent chunks of scripts. Just trying to stop this specific class of data embedding, and by that I mean the use of OP_FALSE in general, itself becomes a game of cat and mouse with many other options users can turn to.

Disabling each of them requires the deployment of a softfork, a massive coordination effort across the entire ecosystem, and right after succeeding users can trivially modify their software to use another method. Metaprotocols can adapt much faster than Bitcoin. Mind you, this is solely dealing with this one class of ways to embed data. 

Let’s entertain the hypothetical reality where all mechanisms using OP_FALSE have been restricted (ignoring both the complication in identifying all of them and coordinating the fork, as well as the potential for unintentionally restricting other use cases of Bitcoin), users can simply create fake public keys. There is nothing in the Bitcoin protocol that verifies a public key is a valid public key, it is simply a random arbitrary string included in an output’s locking script. 

Now imagine a world where Bitcoin did include a mechanism that forced validation of a public key before allowing money to be sent to it. That would solve that problem right?

Wrong. 

You can embed the data indirectly using the private key. But private keys don’t ever actually get put on-chain right? No they don’t, but a signature nonce is. A nonce is a random value used in the construction of a cryptographic signature. This is required to protect your private key, because without using one a cryptographic signature is insecure, and can leak your private key to an attacker. Even using a poorly selected, or weak, nonce can allow that to happen. 

People can intentionally use a weak nonce, and actually use the arbitrary data itself as a private key. The only way this can be prevented is a centralized authority whitelisting private keys, i.e. completely centralizing the ability to use Bitcoin behind a gated authority. 

These examples are not even comprehensive, there are many other methods I can think of to embed arbitrary data in the blockchain, and I am certain many more that I can’t. 

Attempting to play whackamole with all of them simply wastes the time and resources of the entire ecosystem trying to coordinate softforks to address each of them, a massively complex and costly effort, and at the end of the day there are still methods that are not possible to prevent at all without completely breaking the core Bitcoin protocol itself. 

Why User Will Continue Doing This

I am sure plenty of people reading this are thinking “we just have to do this a few times and people will stop trying, they won’t go through all the extra effort.” That attitude is completely disconnected from reality for multiple reasons. 

I want you to think about the two reasons that people would engage in this type of behavior in the first place. Either it is providing real utilitarian benefits to them, i.e. serving a real purpose in their lives that provides value not purely rooted in speculation, or it is pure speculation. 

Let’s look at the first case. There is some meaningful utility value provided, that cannot be provided in some other way, or at least not to the same extent, or same security guarantees, etc. Why would these users not keep adapting their protocol to route around whatever restrictions are put in place to prevent their use case at the consensus level?

This hypothetical protocol is a real thing to these people, something providing some necessary or valuable functionality to them. All of them have an incentive to adapt the protocol to work around whatever new restrictions are added.

Now let’s look at the second case, it is purely a speculative use case, i.e. NFTs or some form of collectible or token. These types of things are fueled by pure speculative mania, massive amounts of money are thrown at them in a game of musical chairs with everyone playing to get out the door with profit because the mania dissipates and collapses on itself. 

These things are always cyclical, never persistently maintained, and come and go. What makes you think that restricting one form of creating such assets will disincentivize people from making new ones? I’ll remind you at this point that the “transfer of ownership” with these things on Bitcoin occurs through Ordinals. That particular metaprotocol is literally impossible to block or prevent by any means at all. 

Nothing about restricting specific mechanisms to embed data on-chain prevents the transfer or resale of assets previously created using that mechanism, so nothing can be done to prevent those assets that already existed from being traded. 

People who engage in these activities are degenerates, they blindly chase whatever opportunity they can find for a quick buck. Do you think preventing them from making new assets of a certain type will stop them? Forcing them to use new mechanisms will probably actively drive demand for those new types of assets. It won’t be a disincentive, it will be a proactive incentive. 

The new mechanism will become desirable to them because of the controversy value. This is simply a losing game, which as I demonstrated in the section above ends with the use of mechanisms that are literally not possible to prevent. 

The Rational Course of Action

It is impossible to stop the embedding of arbitrary data in general in Bitcoin. It is possible to stop some specific methods of embedding data, but not the practice in general. So why are we fighting these things?

All we can do at the end of the day is keep pushing these use cases into more inefficient methods that cause a large negative impact on the network as a whole. Leaving the currently supported means, which in the grand scheme of things are very efficient in terms of network resource use, is the rational move to make. 

Trying to expunge the practice of embedding data in Bitcoin is both impossible, but trying is ultimately self destructive. It leads us down a path that ultimately constrains and limits Bitcoin’s use as money, and still in the end ultimately fails. 

It is simply cutting your nose off to spite your face.

This post You Cannot Stop Bitcoin Metaprotocols first appeared on Bitcoin Magazine and is written by Shinobi.