Open Ledger vs Script Review: BIP110 Attempts to Regulate "Junk Data", Why It Collapsed Early.

Written by: Brandon Black

Translated by: AididiaoJP, Foresight News

In the small circle of crypto Twitter, the proposal for "Reducing Data Temporary Soft Fork" (i.e., BIP110) put forward by @dathon_ohm has caused significant debate over the past year.

The core logic of this proposal is: Certain Bitcoin transactions that insert data in the locking or unlocking scripts can be interpreted as additional information by other software beyond the meaning of the Bitcoin script itself. Supporters see this as violating network principles.

They believe that reducing such transactions is sufficient to justify this most "confiscatory" Bitcoin soft fork to date—its deployment speed is much faster than the last two soft forks, and the activation threshold is lower.

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

This is similar to the principle of free speech: If it only protects the speech we like, it is meaningless. Bitcoin’s open access is the same—if it only allows transactions we approve of, it loses its significance. Therefore, we do not need to censor how others construct their ledger entries, just as we do not wish for others to censor our entries.

Supporters of BIP110 might say, "Of course, but this only applies to non-monetary entries! What about pure monetary transactions?" The reality is that there is no clear distinction. Every Bitcoin transaction creates a record in the ledger by satisfying certain conditions of a locking script—consuming input UTXOs and generating new output UTXOs.

The size of a transaction's script being larger or smaller is completely irrelevant to node operators or ordinary users. First, I do not care at all about the details of others' transactions; it is no different from what someone orders at a café, irrelevant to me. Second, Bitcoin nodes themselves do not make such distinctions. Transactions are simply valid or invalid, and the verification costs vary (for instance, large multi-signature transactions have a high verification cost, while some Ordinals or OP_RETURN are relatively cheap).

Some may argue that if Bitcoin cannot be used "in other ways" like gold, it will become a better monetary asset. Imagine if gold could not be used for jewelry or industrial purposes; it might be a purer form of currency. But it is precisely those physical properties that make gold an excellent currency that also make it highly popular in the jewelry and industrial sectors.

The same goes for Bitcoin: It is because it allows anyone to pay to write data that we cannot control how others will interpret that data. No matter how we restrict the script structure, there will always be someone who can interpret those entries in other ways using software outside of Bitcoin. Thus, like gold, we must accept that "other uses" are inevitable. In the gold market, this leads to price distortions caused by fluctuations in non-monetary demand; in Bitcoin, it may lead to rising transaction fees when demand for block space surges.

However, Bitcoin has two additional advantages over gold. First, creating Bitcoin transactions that can be interpreted in alternative ways does not directly affect the market for Bitcoin as an asset itself—unlike gold, the amount of Bitcoin used for these "additional uses" is actually quite small. Second, the Bitcoin protocol was designed from the beginning with mechanisms to minimize the burden of such "additional interpretations" on the verification network. It limits the block size and the number of signatures (sigops) in transactions, which are the parts with the highest verification costs for nodes.

These early-set restrictions were precisely to prevent high-frequency and high-volume abuse of the ledger. It is these restrictions that have driven the birth of second-layer innovations like Lightning Network, Ark, Spark, and Cashu. Even if the surge in block space demand caused by "non-monetary" data occurs, it actually promotes the use of these more efficient scaling solutions—they can record less content on the main chain.

Now that BIP110's so-called justification has been clearly articulated (and it is obviously untenable), let’s take a look at what it actually aims to change.

BIP110 will restrict the size of locking scripts, limit the number of alternative scripts available in Taproot, render Taproot attachments (annex) ineffective, remove all upgradable witness versions and Tapscript versions, remove all upgradable opcodes in Tapscript, and disable OP_IF and OP_NOTIF in Tapscript. These restrictions apply only to UTXOs created within approximately 52414 blocks (about one year) after activation.

Additionally, BIP110 lowers the miner readiness signal threshold to 55% (previous soft forks typically required over 90%) and establishes a node enforcement activation mechanism: If signals are insufficient before block 961632, nodes executing the rule will treat unsignaled blocks as invalid, thereby forcing the lock change at block 963648 and activation at block 965664.

This will be the most radical limitation on Bitcoin scripts since 2010 when Satoshi disabled multiple opcodes due to a severe vulnerability (CVE-2010-5137). It seeks to push this change with an unprecedentedly low threshold, extremely short activation time (from BIP number to activation in less than 9 months), and very little code review—just because someone is interpreting ledger entries in ways disapproved by supporters.

Ironically, those using the "disapproved" data have already updated their software to be prepared: 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 simply impossible to restrict how others interpret entries with external software.

In summary, BIP110 attempts to do something impossible—restrict how users utilize an open-access ledger—while the issues it claims to address have already been well managed by Bitcoin's existing protocol restrictions. It seeks to force the change through an irresponsible short timeline, a hasty code review, and disregard for ecological consensus. Fortunately, Bitcoin is not such a fragile system, and such reckless modification attempts will not succeed.

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