Bitcoin "Anti-Spam Data" Soft Fork BIP110: Miners' Collective Boycott, Already Doomed to Fail?

Author: Brandon Black

Compiled by: AididiaoJP, Foresight News

In the small circle of Crypto Twitter, the proposal for a "Reduce Data Temporary Soft Fork" (i.e., BIP110) put forward by @dathon_ohm has sparked intense debate over the past year.

The core logic of this proposal is: data stuffed into certain Bitcoin transactions within the locking script or unlocking script, beyond the meaning of the Bitcoin script itself, can be interpreted as additional information by other software. Supporters view this as violating network principles.

They believe that reducing such transactions is sufficient to justify this most "confiscatory" Bitcoin soft fork to date—it deploys much faster than the recent two soft forks and has a lower activation threshold.

Bitcoin is essentially an open-access, censorship-resistant distributed ledger. Anyone willing to pay sufficient fees and persuade block template builders and miners to include transactions can write content into the ledger. The fundamental value distinguishing Bitcoin from all other ledger systems lies in this openness. Without it, the Bitcoin ledger is no different from a bowling alley scoreboard. Because of this open access, we all know Bitcoin will be used by people we dislike.

This is like the principle of freedom of speech: it is meaningless if it only protects speech we like. The same applies to Bitcoin's open access—if only transactions you and I approve of are allowed, it loses its meaning. Therefore, we do not need to censor how others construct their ledger entries, just as we do not want others to censor our entries.

Supporters of BIP110 might say: "Sure, but this is only for non-monetary entries! What about those purely monetary transactions?" The reality is, there is no such clear distinction. Every transaction on Bitcoin creates a record in the ledger by satisfying the conditions of a locking script—consuming input UTXOs and generating new output UTXOs.

Whether a transaction's script is larger or smaller is completely irrelevant to node operators or ordinary users. First, I simply do not care about the details of others' transactions, just as what others order at a coffee shop has nothing to do with me. Second, Bitcoin nodes themselves do not make this distinction. Transactions are either valid or invalid, with varying verification costs (e.g., large multisig transactions have high verification costs, while certain Ordinals or OP_RETURN are relatively cheap).

Some may argue that Bitcoin would become a better monetary asset if it could not be utilized in "other ways," like gold. Imagine if gold could not be used for jewelry or industrial purposes; perhaps it would be more purely monetary. But precisely those physical properties that make gold an excellent monetary asset also make it popular in jewelry and industry.

The same applies to Bitcoin: precisely because it allows anyone to write data by paying fees, we cannot control how others interpret this data. No matter how we restrict script structure, someone can always interpret these entries in other ways using software outside of Bitcoin. So, like gold, we must accept that "other uses" are inevitable. In the gold market, this leads to price distortions from fluctuations in non-monetary demand; in Bitcoin, this may lead to fee increases when block space demand surges.

However, Bitcoin has two advantages over gold. First, creating Bitcoin transactions that can be interpreted alternatively does not directly affect the market of Bitcoin as an asset itself—unlike gold, the amount of Bitcoin used for these "extra purposes" is actually very small. Second, the Bitcoin protocol designed mechanisms from the start to minimize the burden of such "extra interpretation" on the validation network. It limits block size and the number of signatures (sigops) in transactions, which are the most costly parts for nodes to validate.

These limits set early on are precisely to prevent high-frequency, high-volume abuse of the ledger. It is these limits that drove the birth of Layer 2 innovations like Lightning Network, Ark, Spark, Cashu, etc. Even if block space demand surges due to "non-monetary" data, it instead promotes the use of these more efficient scaling solutions—they can record less content on the mainchain.

Since the so-called reasons for BIP110 have been clarified (and are obviously untenable), let us look at what it actually wants to change.

BIP110 will limit the size of locking scripts, limit the number of alternative scripts available in Taproot, invalidate Taproot annexes (annex), remove all upgradable witness versions and Tapscript versions, remove all upgradable opcodes in Tapscript, and disable OP_IF and OP_NOTIF in Tapscript. These limits apply only to UTXOs created within approximately 52,414 blocks (about one year) after activation.

In addition, BIP110 lowers the miner ready signal threshold to 55% (previous soft forks usually required over 90%), and sets a node forced activation mechanism: if signals are insufficient by block 961,632, nodes enforcing this rule will treat blocks without signals as invalid, thereby forcing the change to lock in at block 963,648 and activate at block 965,664.

This will be the most radical restriction on Bitcoin script since Satoshi disabled multiple opcodes due to a serious vulnerability (CVE-2010-5137) in 2010. It seeks to push this change with an unprecedentedly low threshold, extremely short activation time (less than 9 months from BIP number to activation), and minimal code review—just because someone is interpreting ledger entries in ways supporters do not approve of.

More ironically, those using the "opposed" data have already updated their software to prepare: even if BIP110 activates, they can continue to embed similar data. Many of us predicted this in advance, because on an open public ledger, it is fundamentally impossible to restrict how others interpret entries using external software.

In summary, BIP110 attempts to do something impossible—restrict how users of an open-access ledger use it—while the problem it claims to solve is actually handled well by Bitcoin's existing protocol limits. It also wants to force this through with an irresponsible short timeline, hasty code review, and disregarding ecosystem consensus. Fortunately, Bitcoin is not such a fragile system, and this reckless modification attempt will not succeed.

Miners have clearly rejected BIP110, and developers, investors, KOLs, and the business community have also spoken out against it. By August this year, this "attack" on Bitcoin consensus rules will end in failure, and Bitcoin will become stronger because of it, continuing to produce blocks at a stable pace—the next block.