“`html
This is an unavoidable technological truth. Currency itself is merely a ledger, a record of ownership. Even tangible cash is essentially distributing that “database” in the physical realm. There’s no need to refer to a central ledger for verification, as the simple act of handing it over is that verification process. The “entries” in this ledger are circulated independently of a central record. Bitcoin is fundamentally a digital database striving to replicate the key characteristic of its physical counterpart known as cash: absence of a database operator’s consent to utilize your funds.
Imagine the absurdity of attempting to prevent individuals from altering dollar bills. How many of you have stamped “Buy Bitcoin” onto fiat money? Altering a banknote in the United States constitutes a federal offense. You could face 6 months of imprisonment for it. Does that deter anyone?
Do you genuinely believe this could be enforced anywhere? Do you recall Where Is George? People would stamp a website on dollar bills so they could enter serial numbers upon receipt and monitor where cash notes were circulating geographically.
Artists create innate murals and collages on banknotes. You essentially cannot halt it.
Why is there a current of magical reasoning that suggests this is achievable simply because the database is digital?
By its very design, Bitcoin necessitates support for the inclusion of arbitrary data (read: data that cannot be pre-determined or defined) to enable users to transact. You can’t anticipate how much money you’ll send in advance (the satoshi field in outputs), where it will be sent (the script field), or at which blockheight you might wish to utilize it (the nLocktime field in a transaction, or the nSequence field in an input).
Without permitting these components of arbitrary data, the existence of Bitcoin as a system is impossible.
Metaprotocols
A Bitcoin metaprotocol is a protocol layered atop the fundamental protocol, Bitcoin, that interprets the data and actions of the underlying protocol through the lens of additional rules that do not exist within that basic protocol.
A historical instance of this would be the Counterparty (XCP) protocol. Utilizing OP_RETURN, an opcode in Bitcoin script that directly pushes arbitrary data to the stack, creating an unspendable output that can be disregarded by the UTXO set, XCP embeds its own metaprotocol messages.
These messages enable the issuance of new tokens, the transfer of tokens by defining amounts being sent and their destinations, along with other messages that facilitate trustless exchanges on-chain between XCP itself and any other tokens issued through the protocol.
The Bitcoin protocol itself doesn’t comprehend or concern itself with any of these messages. They are interpreted by supplementary software that operates on top of Bitcoin. It is entirely feasible for anyone using Bitcoin to create completely invalid XCP messages and have them confirmed on-chain, yet the XCP software won’t recognize them as valid. The individual crafting these invalid messages is simply squandering their own money on unnecessary transactions.
Absolutely nothing can prevent individuals from interpreting valid data on Bitcoin through the lens of additional rules external to the Bitcoin protocol in this manner.
Ordinals operate in a remarkably similar fashion. Users designate a unique ‘serial number’ to every satoshi mined and have established their own accounting system to interpret the input and output ordering in a transaction, tracing where “individual satoshis” are sent during transactions.
The Bitcoin protocol itself remains entirely unaware of this external protocol, and nothing can hinder users from interpreting valid Bitcoin transactions in this capacity. Anyone can interpret the data presented on the blockchain in whatever manner they choose, applying any additional constraints they wish that do not conflict with the base Bitcoin protocol rules.
Nothing prevents individuals from crafting invalid or malicious metaprotocol messages and confirming those onto the blockchain; however, users operating metaprotocol clients will simply disregard them as invalid. This is the fundamental distinction between the Bitcoin protocol itself and metaprotocols. Bitcoin consensus rules prevent protocol invalid messages from ever being included in the blockchain; metaprotocols do not (or rather cannot).
Data Embedding
The distinction between the two above metaprotocols is that one necessitates embedding additional data on-chain to function (XCP), while the other does not (Ordinals). Thus, you might assume that you can simply obstruct protocols requiring extra data embedding by preventing that data from being embedded in the first place.
While it’s true that specific mechanisms for data embedding could be stopped by softforking that particular mechanism out of the protocol, making transactions utilizing that mechanism invalid, you cannot prevent data from being embedded in general.
Consider the “Inscription envelope.” This is merely a specific method of ensuring that the data embedded in a spending witness is never actually executed. This is achieved using OP_FALSE, which pushes a 0 (or a False value that fails verification) onto the stack before the OP_PUSHes that actually embed the data. This prompts the script interpreter to skip verifying the data following the OP_FALSE. The key functionality required is placing a 0 onto the stack.
If you invalidate by consensus the use of this particular script format, alternate methods will still allow a 0 to be placed on the stack, or ensure the script interpreter executes verification and processing of subsequent segments of scripts. Simply trying to prevent this specific class of data embedding, particularly involving the OP_FALSE in general, becomes a game of cat and mouse with various other options available to users.
Disabling each of them necessitates the deployment of a softfork, a massive coordination effort across the entire ecosystem, and immediately after succeeding, users can easily modify their software to utilize another approach. Metaprotocols can adapt much more swiftly than Bitcoin. Note, this is solely addressing this one category of techniques to embed data.
Let’s entertain the hypothetical scenario where all mechanisms utilizing OP_FALSE have been prohibited (overlooking both the complications in identifying all of them and coordinating the fork, along with the potential for unintentionally restricting other Bitcoin use cases), users can simply generate fake public keys. There is nothing in the Bitcoin protocol that verifies a public key as a valid public key; it’s simply a arbitrary string included in an output’s locking script.
Now envision a scenario where Bitcoin did include a mechanism that mandated validation of a public key before allowing funds to be sent to it. That would resolve that issue, right?
Incorrect.
You can embed the data indirectly utilizing the private key. However, private keys are never actually placed on-chain, are they? No, they aren’t; but a signature nonce is. A nonce is a random value employed in crafting a cryptographic signature. This is necessary to safeguard your private key, because without one, a cryptographic signature is insecure and could expose your private key to an attacker. Even using a poorly selected or weak nonce can facilitate that leakage.
“““html
Individuals can deliberately utilize a feeble nonce and actually employ the random data itself as a confidential key. The sole method to prevent this is a centralized entity whitelisting private keys, that is, entirely centralizing the capability to utilize Bitcoin behind a restricted authority.
These illustrations are not even exhaustive, there are numerous other techniques I can consider to incorporate random data into the blockchain, and I am sure there are many more that I cannot.
Attempting to play whack-a-mole with all of them merely squanders the time and resources of the entire ecosystem striving to coordinate soft forks to tackle each of them, a massively intricate and expensive endeavor, and at the end of the day there are still techniques that cannot be prevented at all without fundamentally disrupting the core Bitcoin protocol itself.
Why Users Will Keep Engaging in This
I am certain many readers here are thinking, “we just need to do this a few times and individuals will cease attempting; they won’t go through all the additional hassle.” That mentality is entirely detached from reality for numerous reasons.
I want you to ponder the two reasons why individuals would partake in this type of behavior in the first place. Either it is providing tangible utilitarian benefits, i.e. fulfilling a genuine purpose in their lives that supplies value not solely grounded in speculation, or it is merely speculation.
Let’s explore the first scenario. There is some significant utility value provided, which cannot be offered in some other manner, or at least not to the same degree or with the same security assurances, etc. Why would these users not continue to adjust their protocol to circumvent whatever limitations are imposed to obstruct their use case at the consensus level?
This hypothetical protocol holds real significance for these individuals, something delivering essential or valuable functionality to them. Each of them is incentivized to modify the protocol to bypass whatever new restrictions are implemented.
Now let’s examine the second scenario; it is purely a speculative use case, i.e. NFTs or some form of collectible or token. These types of endeavors are driven by pure speculative fervor, enormous sums of money are invested in them in a game of musical chairs with everyone aiming to exit with profit before the mania dissipates and collapses on itself.
These phenomena are always cyclical, never consistently sustained, and come and go. What leads you to believe that restricting one method of creating such assets will deter people from producing new ones? I’ll remind you at this juncture that the “transfer of ownership” of these items on Bitcoin transpires through Ordinals. That particular metaprotocol is literally impossible to block or prevent by any means whatsoever.
Nothing regarding the restriction of specific techniques to embed data on-chain prevents the transfer or resale of assets already created using that method, so nothing can be done to inhibit those assets that have existed from being traded.
Individuals involved in these activities are degenerates; they impulsively pursue whatever opportunity they can discover for a quick profit. Do you think that hindering them from creating new assets of a particular type will halt them? Forcing them to adopt new methodologies will likely actively enhance demand for those new types of assets. It won’t serve as a disincentive; it will function as a proactive incentive.
The new mechanism will become attractive to them due to the controversy surrounding it. This is simply a losing endeavor, which as I illustrated in the previous section culminates in the utilization of mechanisms that are effectively not preventable.
The Rational Path Forward
It is impossible to halt the embedding of random data in general within Bitcoin. It is feasible to stop certain specific methods of embedding data, but not the practice as a whole. So why are we battling against these occurrences?
All we can ultimately do is continue pushing these use cases into less efficient methods that cause a substantial negative impact on the network overall. Retaining the currently supported means, which in the grand context are very efficient concerning network resource utilization, is the rational decision to make.
Attempting to eradicate the practice of embedding data in Bitcoin is both unfeasible and ultimately self-destructive. It leads us down a path that ultimately restricts and limits Bitcoin’s utility as currency, and still in the end, it ultimately fails.
It is akin to cutting off your nose to spite your face.
Source link
“`
