Bitcoin is a database.
This is an inevitable reality of technology. Money itself is just a ledger, a record of who has what. Even physical cash simply distributes its “databases” in the real world. No more checking against the central ledger to check anything. The “entries” in that ledger are passed around disconnected from the central record. Bitcoin is a digital database that attempts to replicate the most important properties of a physical property known as cash. You do not need permission to spend money from a database operator.
Imagine the futileness of trying to stop people from tainting the dollar letter. How many people have engraved “Buy Bitcoin” on Fiat currency? Spoiling US banknotes is a federal crime. You can spend six months in prison for it. Does that stop someone?
Do you seriously think that it can be enforced anywhere? Do you remember where George is? People stamp websites on dollar bills so that people can enter their serial numbers when they get them, allowing them to track where cash notes are circulating geographically.
Artists perform innate murals and collages with cash notes. You can’t literally stop it.
Why are there any magical thinking stocks that believe this is possible just because the database is digital?
By its nature, Bitcoin must support any data (read: read data that is known or impossible to define beforehand: read data: read data) in order for users to be able to trade. You don’t know in advance what block height (nlocktime field of a transaction, or n-sequence field in transaction input) you send it (script field) money (atshi field) (script field) and what block height (nlocktime field of a transaction, or n-sequence field in transaction input).
Without allowing any of these data, Bitcoin cannot exist as a system.
Metaprotocol
The Bitcoin Meta Protocol is a protocol layered above a base protocol that interprets the data and actions of the underlying protocol through a lens of additional rules that do not exist in the base protocol.
A historical example of this is the Counterparty (XCP) protocol. Simply use op_return to push any data onto the stack, create a negligible output in the UTXO set, and XCP embeds its own metaprotocol messages.
These messages facilitate the issuance of new tokens and transfer of tokens by defining the amount and location they have sent. It also facilitates other messages that allow for unreliable exchange of chain-on-chain between XCP itself and other tokens issued using the protocol.
The Bitcoin protocol itself doesn’t understand or care about these messages. They are interpreted by additional software running on Bitcoin. It is entirely possible to use Bitcoin to create a completely invalid XCP message and have it checked on-chain, but the XCP software does not recognize it as valid. Those who create these invalid messages are simply wasting their own money and creating meaningless transactions.
In this way, we cannot absolutely stop people from interpreting valid data about Bitcoin, via the lens of extra rules outside of the Bitcoin protocol.
Ordinals work in a very similar way. Users assign a unique “serial number” to all the Satoshis that are mined, and create their own accounting system that interprets the order of input and output in transactions, tracking where “individual atoshis” are sent over the course of the transaction.
The Bitcoin protocol itself is not fully aware of this external protocol and can’t do anything to stop users from interpreting valid Bitcoin transactions in this way. Anyone can interpret data published on the blockchain as what they need, and apply additional constraints that do not conflict with the base Bitcoin protocol rules.
There’s nothing preventing people from creating invalid or malicious metaprotocol messages and checking blockchain messages, but users running metaprotocol clients simply ignore them as invalid. This is an important difference between the Bitcoin protocol itself and the Metaprotocol. Bitcoin consensus rules prevent the protocol’s invalid messages from being included in the blockchain, so Metaprotocol is not (or rather not).
Data embedding
The difference between the two metaprotocols above is that one must embed additional data in a chain into the function (XCP), and the other is not (ordinal). So, we might assume that by preventing data from being embedded in the first place, we can simply prevent protocols that require additional data to be embedded.
It is true that a particular mechanism of embedding data can be prevented by preventing that particular mechanism from a protocol, but rendering a transaction that disables that mechanism does not prevent the data from being embedded in general.
For example, consider an “inscription envelope.” This is simply a specific way to ensure that data built into spending witnesses will not actually be implemented. This is done using op_false. This will push 0 (or false positives that cause the failed verification to fail) into the stack before OP_PUSHES where you actually embedded the data. This will cause the script interpreter to skip just by checking the data after OP_FALSE. The important function you need is to place zeros in the stack.
If you want to disable the use of this particular script format with consensus, there is a way to either place zeros on the stack or to ensure that the script interpreter explains the validation and execution of subsequent chunks of the script. Just trying to stop data embedding for this particular class would generally mean using OP_FALSE, but it itself becomes a cat and mouse game with many other options that users can rely on.
To disable each of them, you will need to deploy a soft fork. Large scale Coordination efforts throughout the ecosystem, and subsequent users can easily modify the software and use alternative methods. Metaprotocol can adapt much faster than Bitcoin. Take care, this is it only It deals with this one class of how to embed data.
Let’s entertain a virtual reality where all mechanisms using OP_FALSE are limited (it can ignore both complications when identifying them all, adjusting forks, and unintentionally limit Bitcoin use cases), and users can simply create fake public keys. There is nothing in the Bitcoin protocol that verifies that a public key is a valid public key. This is any random string contained in the output lock script.
Imagine the world of Bitcoin now did Include a mechanism to force public key verification before allowing money to be sent. Does that solve that problem?
It’s wrong.
Data can be embedded indirectly Use the private key. But are private keys not actually placed in chains? No, not so, but the signature Nonse is. Non-CE is a random value used to construct a cryptographic signature. This is necessary to protect the private key. This is because encryption signatures without using one are unstable and can be leaked to the attacker’s private key. Even using unselected or weak non-CE can happen.
People can intentionally use weak non-CE Use any data itself as a private key. The only way this can be prevented is to have a central institution that whitelists private keys, meaning it is to fully centralize the ability to use Bitcoin behind gated authority.
These examples are not comprehensive and there are many other ways I can think of to embed any data in the blockchain, and I’m more sure I can’t.
When you try to play Guacamole with all of them, you simply waste time and resources across the ecosystem and try to adjust your soft fork to deal with each one. On a large scale A complex and expensive effort, and at the end of the day There are still ways to prevent the core Bitcoin protocol itself at all without completely breaking it.
Why users continue doing this
I’m sure there are a lot of people reading this. That attitude is completely detached from reality for multiple reasons.
I want you to think about two reasons why people engage in this type of behavior in the first place. It is pure speculation whether it offers them true utilitarian benefits, that is, it serves the real purpose of their lives that provides value that is not purely rooted in speculation.
Let’s take a look at the first case. Several meaningful utility values are provided. This cannot be provided in any other way. At least there are not the same level or the same security guarantee. Why are these users not continuing to adjust their protocols to introduce restrictions placed to prevent use cases at consensus level?
This hypothetical protocol is real for these people and provides them with the necessary or valuable features. They all have incentives to adapt the protocol to avoid anything that has been added with new restrictions.
Next, let’s look at the second case. It is a purely speculative use case: some form of collectible or token. These types of things are fueled by pure speculative enthusiasts, throwing a ton of money in a musical chair game where everyone plays to get profit and get out the door as the enthusiasts dissipate and collapse.
These things are always periodic, never sustained, they come and go. Why do you think that limiting the one form of creating such assets prevents people from creating new assets? At this point, it reminds us that “transfer of ownership” including these things on Bitcoin occurs through ordinal numbers. That particular meta-protocol is literally impossible to block or prevent in any way at all.
Restricting a particular mechanism to embed data on-chain is something that can be done to prevent the transfer or resale of assets previously created using that mechanism, and to prevent assets that have not already been traded.
Those engaged in these activities will degenerate and they blindly chase every opportunity they can quickly find. Do you think preventing certain types of new assets from creating them will stop them? It will probably force you to use a new mechanism Proactively promote demand For these new types of assets. It is not obstructive, it is an aggressive incentive.
Because it is worth the controversy, new mechanisms become desirable for them. This is simply a lost game and, as demonstrated in the section above, ends with the use of mechanisms that are literally unpreventable.
Rational policy of action
It is not possible to stop embedding any data into Bitcoin. You can stop Some specific methods Embedded data is generally not a practical example. So why are we fighting these things?
What you can do at the end of the day is to keep these use cases pushing into more inefficient ways, and have a major negative impact on the entire network. Leave the currently supported means. This is a very efficient and reasonable move in terms of network resources in the grand scheme of things.
It is both impossible to attempt to erase the practice of embedding data into Bitcoin, but ultimately it is self-destructive. It leads us on the path that ultimately limits and limits us Bitcoin is used as moneyand ultimately fails.
It’s simply cutting off your nose to keep your face still.
You cannot stop the Bitcoin Meta Protocol. It first appeared in Bitcoin Magazine and is written by Shinobu.
