This is a guest post by Brandon Black. The opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc. or Bitcoin Magazine.
Within the small internet bubble of Bitcoin Underlying this proposal is the idea that certain Bitcoin transactions violate the principles of the network by including data in the locking or unlocking script that can be interpreted in one or more additional ways beyond the simple interpretation of the Bitcoin script. According to BIP110 proponents, reducing the use of these transactions is enough to justify the most confiscated Bitcoin soft fork to date, with a dramatically faster deployment timeline and lower activation readiness threshold than the last two soft forks.
Bitcoin is an open-access, censorship-resistant ledger where anyone can write entries, provided they are willing to pay a sufficient fee to convince block template creators and miners to include their transactions. The fundamental value of Bitcoin compared to all other ledger systems is the aforementioned open access. Without it, a Bitcoin ledger would not have the same value as a bowling alley scoreboard. We all know that because of this fundamentally open access, Bitcoin is used by people who don’t like it. Just like the principle of free speech is meaningless unless it applies to speech we don’t like, Bitcoin’s open access is meaningless if it only applies to transactions that you or I approve of. Therefore, we assume that, just as we would like others to inspect our own book entries, we do not want to be involved in the task of inspecting how others compose their book entries.
Proponents of BIP110 might say: “True, but that only applies to:” monetary Entry! You might be wondering, “What about these non-monetary entries?” But in reality, there is no such distinction at all. Every transaction made in Bitcoin is done by meeting the conditions of a lock script to create an entry in the ledger, expending input coins and creating output coins. The fact that one transaction’s script is larger or smaller than another is of no concern to me as a Bitcoin node operator or user. Firstly, I just don’t see other people’s transactions. They are no longer my job. Second, my node doesn’t differentiate between valid and invalid transactions, and either it’s expensive to verify (for large multisig) or it’s expensive to verify (either these ordinals or OP_RETURN).
Some might argue that Bitcoin, like gold, could be a great financial asset if you don’t look at it differently. Imagine what would happen if gold could not be used in industry or jewelry. Surely it might be better for your money. But of course, the same properties that make gold profitable also make it desirable in jewelry and industry. The same applies to Bitcoin. In Bitcoin, the fact that anyone can enter for a fee means we have to give up the idea that we can control how they see that entry. No matter what restrictions we place on the structure of entries, there is always the possibility of creating entries that can be interpreted differently by non-Bitcoin software. Therefore, I accept that other uses are inevitable, whether for Bitcoin or gold. In the case of gold, this creates market distortions when non-monetary demand increases or decreases. Bitcoin can experience periods of high transaction fees when demand for limited block space increases.
Bitcoin has two advantages over gold. First, Bitcoin transactions that can be viewed in other ways do not affect the market for Bitcoin itself. Unlike gold, only a small amount of Bitcoin is allocated for these uses. Second, Bitcoin already has a protocol designed to minimize the cost to the verification network of such other interpretations. Bitcoin limits both the block size and the number of signatures that can be used in a transaction. These are the largest costs for validating a node, and protocol limits on these have been in place since the early days of Bitcoin, precisely to prevent abuse due to high or heavy use of the ledger. These limitations are already driving innovations like the Lightning Network, Ark, Spark, and Cashu. Even the boom in demand for block space caused by these “non-monetary” ledger entries (yes, that sounds ridiculous) has increased the use of these scaling solutions that require fewer entries on the main ledger.
Now that the legitimacy of BIP110 has been examined and hopefully shown to be woefully lacking, let’s look at the proposed changes themselves. BIP110 limits the size of lock scripts, limits the number of alternative scripts in taproot, disables taproot appendixes, removes all upgradable watch and tapscript versions, removes all tapscript upgradeable opcodes, and disables tapscript OP_IF and OP_NOTIF. All of these limits apply to UTXOs created within 52414 blocks (approximately 1 year) after activation. BIP110 also proposes a 55% miner readiness signaling threshold instead of the 90%+ threshold used in previous miner signaling soft forks. If 55% of the blocks do not signal ready before block 961632, the node applying BIP110 processes the block. do not have Block 963648 forces the changes to be locked and block 965664 signals them as invalid, ready for activation.
BIP110 is the most comprehensive restriction on Bitcoin scripts since Satoshi famously deactivated many opcodes in response to a critical vulnerability (CVE-2010-5137) in 2010. It proposes activation by minor signals with unprecedentedly low thresholds and forced node activation less than nine months after the date the BIP is assigned a number. This is all because (as mentioned above) others are viewing certain ledger entries in ways not approved by BIP110 proponents. To make matters worse, those using such disapproved ledger entries have already updated their software to continue creating such entries even if BIP110 becomes Bitcoin’s consensus rule set. Of course, this was a predictable outcome (many of us explicitly predicted it). This is because it is essentially impossible to restrict how others use external software to analyze entries in open access public ledgers.
In summary, BIP110 is a proposal to do the impossible (restrict how users of an open access ledger can use that ledger) in response to a problem already fully addressed by Bitcoin’s existing protocol limitations. It proposes to do this impossible with irresponsibly short activation timelines, with incredibly limited code reviews, regardless of whether the changes reach some kind of ecosystem consensus. Fortunately, Bitcoin is not such a delicate system that reckless attempts to change it will succeed. Not only have miners flatly rejected BIP110, but developers, investors, influencers, and other voices across the corporate world have also spoken out against the change. In August, this particular attack on Bitcoin’s consensus rules will strengthen Bitcoin through failure and the network will continue its steady rhythm of ticking towards the next block.
The post Bitcoin Soft Forks Tried to Crack Down on “Junk Data” — and Why They’re Already Failing appeared first on Bitcoin Magazine and written by Brandon Black.
