Author: Brandon Black
Compiled by: AididiaoJP, Foresight News
Within the small circle of Crypto Twitter, the past year has seen heated debates regarding the "Reduce Data Temporarily Soft Fork" proposal (i.e., BIP110) put forward by @dathon_ohm.
The core logic of this proposal is: certain Bitcoin transactions embed data in their locking or unlocking scripts that, aside from their inherent Bitcoin script meaning, can also be interpreted as additional information by other software. Proponents view this as a violation of network principles.
They believe that reducing such transactions is sufficient justification for this soft fork, which they consider the most "confiscatory" in Bitcoin's history to date—it would deploy significantly faster than the two most recent soft forks and have a lower activation threshold.
Bitcoin is fundamentally an open-access, censorship-resistant, distributed ledger. Anyone can write content onto this ledger as long as they pay a sufficient fee to convince block template builders and miners to include their transaction. The core value that distinguishes Bitcoin from all other ledger systems lies precisely in this openness. Without it, the Bitcoin ledger would be no different from a bowling alley's scoreboard. Because of this open access, we all know Bitcoin will be used by people we dislike.
This is akin to the principle of free speech: if it only protects speech we like, it is meaningless. The same goes for Bitcoin's open access—if it only permits transactions you and I approve of, it loses its significance. Therefore, there is no need for us to censor how others construct their ledger entries, just as we wouldn't want them to censor ours.
Proponents of BIP110 might argue: "Of course, but this only applies to non-monetary entries! What about purely monetary transactions?" The reality is that no such clear distinction exists. Every single transaction on Bitcoin creates a record on the ledger by satisfying the conditions of a locking script—consuming input UTXOs and generating new output UTXOs.
Whether a transaction's script is slightly larger or smaller is completely irrelevant to node operators or ordinary users. Firstly, I don't care about the specifics of other people's transactions; that's as much my business as what someone orders at a coffee shop. Secondly, Bitcoin nodes themselves do not make such distinctions. Transactions are either valid or invalid, with varying verification costs (e.g., large multi-signature transactions are costly to verify, while certain Ordinals or OP_RETURN transactions are relatively cheap).
Some argue that Bitcoin would be a better monetary asset if, like gold, it couldn't be utilized in "other ways." Imagine if gold couldn't be used for jewelry or industrial purposes; it might then be a purer form of money. However, it is precisely the physical properties that make gold an excellent form of money that also make it highly desirable for jewelry and industry.
The same applies to Bitcoin: precisely because it allows anyone who pays to write data, we have no control over how others might interpret that data. No matter how we restrict script structures, there will always be people using external software to interpret these entries in other ways. So, like with gold, we must accept that "other uses" are inevitable. In the gold market, this leads to price distortions due to fluctuations in non-monetary demand; in Bitcoin, it may lead to increased transaction fees 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 for Bitcoin as an asset itself—unlike gold, the amount of Bitcoin used for these "additional purposes" is actually very small. Second, the Bitcoin protocol was designed from the outset with mechanisms to minimize the burden these "alternative interpretations" place on the verification network. It limits block size and the number of signature operations (sigops) per transaction, which are the most costly aspects of node verification.
These early-implemented limits were precisely intended to prevent high-frequency, high-volume abuse of the ledger. It is these limits that have driven innovation in layer-two solutions like the Lightning Network, Ark, Spark, and Cashu. Even if "non-monetary" data causes a surge in block space demand, it actually promotes the use of these more efficient scaling solutions—which record less content on the main chain.
Now that the so-called rationale for BIP110 has been explained (and is clearly untenable), let's examine what it actually proposes to change.
BIP110 would limit the size of locking scripts, restrict the number of alternative scripts available in Taproot, invalidate the Taproot annex, remove all upgradeable witness versions and Tapscript versions, remove all upgradeable opcodes in Tapscript, and disable OP_IF and OP_NOTIF in Tapscript. These restrictions would only apply to UTXOs created within approximately 52,414 blocks (about one year) after activation.
Furthermore, BIP110 lowers the miner readiness signaling threshold to 55% (past soft forks typically required over 90%) and implements a node-enforced activation mechanism: if insufficient signaling occurs by block height 961,632, nodes enforcing the rule would treat unsignaled blocks as invalid, thereby forcing the changes to lock in at block height 963,648 and activate at block height 965,664.
This would be the most aggressive restriction on Bitcoin scripting since Satoshi disabled several opcodes in 2010 due to a critical vulnerability (CVE-2010-5137). It aims to push this change with an unprecedentedly low threshold, an extremely short activation timeline (less than 9 months from BIP numbering to activation), and minimal code review—all justified solely by the fact that some people are interpreting ledger entries in ways the proponents disapprove of.
Ironically, those using the "objectionable" data have already updated their software in preparation: even if BIP110 activates, they will be able to continue embedding similar data. Many of us predicted this in advance because, on an open public ledger, it's fundamentally impossible to restrict how users interpret entries with external software.
In summary, BIP110 attempts to do the impossible—restrict how users of an open-access ledger can use it—while claiming to solve a problem that Bitcoin's existing protocol limitations already handle quite well. It also seeks to force this through with an irresponsible short timeline, hasty code review, and disregard for ecosystem consensus. Fortunately, Bitcoin is not such a fragile system, and this reckless attempt at modification will not succeed.
Miners have already clearly rejected BIP110, and developers, investors, KOLs, and the business community have all voiced opposition. By August this year, this "attack" on Bitcoin's consensus rules will end in failure, and Bitcoin will emerge stronger, continuing to produce blocks at a steady pace—one block at a time.
