The Bitcoin Softfork That Tried to Police “Junk Data” – and Why It’s Already Failing

Brandon Black

This is a guest post by Brandon Black. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.

Within the little internet bubble of Bitcoin X (formerly Bitcoin Twitter or Crypto Twitter) there has been a lot of noise in the past year about @dathon_ohm’s proposal for a Reduced Data Temporary Softfork, also known as BIP110. The rationale for this proposal is the idea that certain Bitcoin transactions have violated the principles of the network by including data in their lock or unlock scripts that can be interpreted in one or more additional ways beyond their regular Bitcoin script interpretation. According to BIP110’s proponents, reducing the use of these transactions is sufficient justification for the most confiscatory Bitcoin softfork to date, on an implementation timeline that is dramatically faster than the two most recent softforks, and with a lower activation readiness threshold.

Bitcoin is an open-access, censorship-resistant ledger to which anyone can write entries if they are willing to pay fees sufficient to convince templaters and miners to include their transaction. The fundamental value of Bitcoin vs. all other ledger systems are the aforementioned open access. Without it, Bitcoin’s ledger has no more value than the bowling alley’s scoreboard. Because of this fundamental open access, we all know that Bitcoin will be used by those we hate. Like the principle of free speech, which is meaningless unless it applies to speech we don’t like, Bitcoin’s open access would be meaningless if it only applied to transactions that you or I approve. I would therefore assume that we don’t want to be in the process of inspecting how other people structure their financial records any more than we want them to inspect our records.

BIP110 supporters might say, “Sure, but that only applies to monetary entrances! What about these non-monetary entries?”, but the reality is that there is simply no such distinction. Every transaction made on Bitcoin is made by satisfying the conditions of a lock script to make an entry in the ledger that consumes input coins and creates output coins. The fact that one transaction’s scripts are larger or smaller than another is immaterial to me, as the Bitcoin operator is immaterial first, as it is immaterial to me. Other people’s transactions They is no more my business than other people’s orders at the local cafe.Second, there is no such difference between transactions and they are either expensive to validate (like a large multisig) or cheap to validate.

One could argue that Bitcoin, like gold, would be a superior monetary asset if it could not also be seen in other ways. Imagine if gold could not be used in industry or jewelry! It may be true that it would make it better as money. But of course the very same properties that make gold good money also make it desirable in jewelry and industry. The same goes for Bitcoin. The very fact that Bitcoin allows anyone to make an entry if they are willing to pay the fees means we have to give up the idea that we can control how they will view that entry. Regardless of the restrictions we place on the structure of the records, it will always be possible to make records that can be interpreted in other ways by non-Bitcoin software. So both with Bitcoin and with gold we accept that other uses are inevitable. In gold, this leads to distortions in the market as non-monetary demand rises or falls. In Bitcoin, this can lead to periods of higher transaction fees when there is greater demand for its limited block space.

In Bitcoin we have two advantages that gold does not have. First, making Bitcoin transactions that can be viewed in alternative ways does not affect the market for Bitcoin itself. Unlike gold, very little Bitcoin is allocated to these uses. Second, in Bitcoin we have a protocol already designed to minimize the cost to the validation network from such other interpretations. Bitcoin limits both the size of blocks and the number of signatures that can be used in transactions. This is the biggest cost of validating nodes, and the protocol limits for them have been in place since the very early days of Bitcoin, precisely to prevent abuse in any high-frequency or high-volume use of the ledger. These limits have already spurred innovations such as Lightning Network, Ark, Spark, Cashu and many more. 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, which require fewer entries on the ledger.

With the rationale for BIP110 thus examined, and hopefully proven wanting, let’s look at the proposed amendment itself. BIP110 limits the size of lock scripts, limits the number of alternative scripts in taproot, invalidates the taproot annex, removes all upgradable witness and tapscript versions, removes all tapscript upgradable opcodes, and invalidates OP_IF and OP_NOTIF in tapscript. All these restrictions apply to UTXOs created during the 52414 blocks (approximately 1 year) after its activation. BIP110 also proposes a miner alert signaling threshold of 55% instead of the threshold used in previous miner signaled soft forks of 90% or more. If 55% of blocks do not signal readiness before block 961632, nodes enforcing BIP110 will process blocks not signaling readiness as invalid to force the change to lock in by block 963648 and activate at block 965664.

BIP110 would be the most sweeping limitation of Bitcoin script since Satoshi’s famous disabling of many opcodes in response to a critical vulnerability (CVE-2010-5137) back in 2010. It proposes miner-signaled activation with an unprecedented low threshold, and node-forced activation from 9 months was less than 9 months of activation. It does all this because (as discussed above) other people see certain ledger entries in ways that the BIP110 proponents do not approve of. Even worse, the people using such rejected ledger entries have already updated their software to continue making such entries even if BIP110 were to become Bitcoin’s consensus rule set. This was of course a predictable outcome (many of us explicitly predicted it) because it is fundamentally impossible to limit how other people use external software to analyze entries on an open-access public ledger.

In summary, BIP110 is a proposal to do something impossible (restrict how users of an open access ledger use that ledger) in response to a problem already fully solved through Bitcoin’s existing protocol limits. It proposes to do this impossible thing on an irresponsibly short activation timeline, with incredibly limited code review, and regardless of whether the change reaches any kind of ecosystem consensus. Fortunately, Bitcoin is not such a delicate flower in a system that such a foolhardy attempt to change it will succeed. Not only have miners rightfully rejected BIP110, but other voices across the developer, investor, influencer and corporate landscape have spoken out against the changes. By August, this particular attack against Bitcoin’s consensus rules will have made Bitcoin stronger through its failure, and the network will continue its steady rhythm of tick-tock, next block.

Leave a Reply

Your email address will not be published. Required fields are marked *