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 @dathon_ohm Proposal for a Reduced Data Temporary Softfork, also known as BIP110. Underlying this proposal is the idea that some Bitcoin transactions may violate network principles by including lock or unlock script data that can be interpreted in one or more ways besides the simple Bitcoin text interpretation. According to BIP110 proponents, limiting the use of these transactions is sufficient justification for the most forfeited Bitcoin electronic forks to date, on a significantly faster deployment timeline than the two most recent digital forks, and with a lower readiness threshold for activation.
Bitcoin is an open-access, censorship-resistant ledger that anyone can write entries to if they are willing to pay enough fees to convince block block creators and miners to include their transactions. The fundamental value of Bitcoin versus all other ledger systems is the open access mentioned above. Without it, a Bitcoin ledger would have no more value than a bowling alley scoreboard. Mainly because of this open access, we all know that Bitcoin will be used by those we hate. Just as the principle of free speech, which is meaningless unless it is applied to expression we don’t like, open access to Bitcoin would be meaningless if it was only applied to transactions that you or I approve of. So I’m going to assume that we don’t want to be as engaged in examining how other people construct their ledger entries as we are in examining our own.
BIP110 supporters might say: “Sure, but that only applies to monetary Entries! “What about these non-cash entries?”, but the truth is that there is simply no such distinction. Every transaction on Bitcoin is done by fulfilling the conditions of some locking script to be entered into the ledger, which consumes input coins and creates output coins. The fact that transaction texts are larger or smaller than another does not matter to me as an operator or user of a Bitcoin node. First, I simply don’t look at other people’s transactions. It’s not my business any more than other people’s orders at the local coffee shop. Second, my node makes no such distinction, transactions are either valid or invalid, and verifying them is either expensive (like large multi-signatures) or cheap (like one of these or OP_RETURNs).
One could argue that Bitcoin, like gold, would be a superior monetary asset if it could not also be viewed in other ways. Imagine if gold could not be used in industry or jewelry! It may be true that that would make better money. But of course, the same properties that make gold good money also make it desirable in jewelry and industry. The same applies to Bitcoin. The fact that Bitcoin allows anyone to make an entry if they are willing to pay a fee means that we must abandon the idea that we can control how they look at that entry. No matter what restrictions we place on the structure of entries, it will always be possible to make entries that can be interpreted in other ways by programs other than Bitcoin. So, for Bitcoin and gold, we accept that other uses are inevitable. In gold, this leads to market distortions when non-monetary demand increases or decreases. In Bitcoin, this can lead to periods of high transaction fees when there is greater demand for its limited block space.
In Bitcoin, we have two advantages that gold does not have. First, conducting Bitcoin transactions that can be offered in alternative ways does not affect the Bitcoin market itself. Unlike gold, very little Bitcoin is allocated to these uses. Second, in Bitcoin, we have a protocol that is actually designed to reduce the cost to the verification network of verifying such other interpretations. Bitcoin limits the size of blocks and the number of signatures that can be used in transactions. These are the largest costs of contract validation, and protocol limits have been in place since the early days of Bitcoin, specifically to prevent abuse by any high-frequency or high-volume use of the ledger. These frontiers have already spurred innovations like Lightning Network, Ark, Spark, Cashu, and many others. Even the boom in demand for block space caused by these “cashless” ledger entries (yes, that sounds silly) has led to increased use of these scaling solutions, which require fewer entries in the master ledger.
With the justification for BIP110 explored, hopefully woefully lacking, let’s look at the proposed change itself. BIP110 limits the size of lock scripts, limits the number of standby scripts in the master root, makes the master root extension invalid, removes all witness versions and upgradable Tapscript versions, removes all upgradeable Tapscript opcodes, and makes OP_IF and OP_NOTIF invalid in Tapscript. All of these restrictions apply to UTXOs created within 52414 blocks (about one year) after they were activated. BIP110 also proposes a miner readiness signal limit of 55% instead of the limit used in previous soft forks for a miner signal of 90% or more. If 55% of blocks do not indicate readiness before block 961632, nodes enforcing BIP110 will handle the blocks no Invalid signal readiness to force change to lock by block 963648 and activation by block 965664.
BIP110 would be the most comprehensive restriction of the Bitcoin script since Satoshi deactivated several opcodes in response to a critical vulnerability (CVE-2010-5137) back in 2010. It proposes miner-indicated activation with an unprecedented low threshold and forced node activation less than 9 months after the date the BIP number was assigned. It does all this because (as discussed above) other people see some ledger entries in ways that BIP110 supporters disagree with. What’s worse is that the people using these rejected ledger entries have already updated their software to continue making such entries even if BIP110 becomes Bitcoin’s consensus ruleset. This was, of course, an expected outcome (which many of us explicitly expected) because it is fundamentally impossible to restrict how other people use external software to analyze entries in an open-access public ledger.
In short, BIP110 is a proposal to do something impossible (limit how open ledger users can use that ledger) in response to a problem that has already been fully addressed by Bitcoin’s current protocol limits. He proposes doing this impossible thing within a short and irresponsible activation timeline, with very limited code review, and regardless of whether the change reaches any kind of ecosystem consensus. Fortunately, Bitcoin is not such a delicate flower of the system that such a reckless attempt to modify it would succeed. Not only did miners soundly reject BIP110, but other voices across the board – developers, investors, influencers and businesses – spoke out against the changes. In August, this particular attack against Bitcoin’s consensus rules would have made Bitcoin stronger by failing, and the network would continue its steady rhythm of TikTok, the next block.
