Written by: Brandon Black
Compiled by: AididiaoJP, Foresight News
In the small circle of Crypto Twitter, there has been a heated debate over the past year regarding the "Reduction of Data Carriers soft fork" proposal (i.e., BIP110) put forward by @dathon_ohm.
The core logic of this proposal is: certain Bitcoin transactions contain data in their locking scripts or unlocking scripts that, besides the inherent meaning of the Bitcoin script itself, can be interpreted by other software as carrying additional information. Supporters view this as a violation of network principles.
They believe that reducing such transactions is sufficient justification for the most "confiscatory" Bitcoin soft fork to date—its deployment would be faster than the two most recent soft forks, with a lower activation threshold.
Bitcoin is fundamentally an open-access, censorship-resistant, distributed ledger. Anyone can write content onto the ledger by paying a sufficient fee to convince block template builders and miners to include their transaction. The fundamental value of Bitcoin, what distinguishes it from all other ledger systems, lies in this openness. Without it, the Bitcoin ledger would be no different from a bowling alley's scoreboard. Precisely because of this open access, we know Bitcoin will be used by people we dislike.
This is akin to the principle of free speech: if it only protects the speech we like, it is meaningless. The same applies to Bitcoin's open access—if it only permits ledger entries we approve of, it loses its meaning. Therefore, there is no need for us to censor how others construct their ledger entries, just as we wouldn't want others to censor ours.
Supporters of BIP110 might say, "Of course, but this only applies to non-monetary entries! What about purely monetary transactions?" The reality is that there is no clear distinction. Every 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 unimportant to node operators or average users. First, I don't care about the details of other people's transactions, just as I don't care what someone orders at a coffee shop. Second, Bitcoin nodes themselves do not make such distinctions. Transactions are only 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 cheaper).
Some argue that Bitcoin would be a better monetary asset if, like gold, it couldn't be used "in other ways." Imagine if gold couldn't be used for jewelry or industrial purposes—perhaps it would be a purer form of money. But it is precisely the physical properties that make gold a good form of money that also make it popular for jewelry and industrial use.
The same applies to Bitcoin: precisely because it allows anyone to write data by paying a fee, we cannot control how others interpret this data. No matter how we restrict script structures, people will always find ways to interpret these entries differently using software outside of Bitcoin. So, like with 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, it may lead to rising fees during surges in block space demand.
However, Bitcoin has two 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—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 of such "alternative interpretations" on the verification network. It limits block size and the number of signatures in transactions (sigops), which are the most costly parts of node verification.
These early limitations were set precisely to prevent high-frequency, high-volume abuse of the ledger. These very limitations spurred innovations like the Lightning Network, Ark, Spark, Cashu, and other Layer 2 solutions. Even surges in block space demand from "non-monetary" data have encouraged the use of these more efficient scaling solutions—they can record less on the main chain.
Now that the supposed rationale for BIP110 has been explained (and is clearly untenable), let's look at what it actually proposes to change.
BIP110 would limit the size of locking scripts, limit 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 apply only 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-forced activation mechanism: if insufficient signaling occurs before block 961,632, nodes enforcing this rule will treat unsignaled blocks as invalid, thereby forcing the changes to lock in at block 963,648 and activate at block 965,664.
This would be the most radical restriction on Bitcoin scripting since Satoshi disabled several opcodes in 2010 due to a critical vulnerability (CVE-2010-5137). It seeks 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 merely by the fact that people are interpreting ledger entries in ways the proponents disapprove of.
More ironically, those using the "disapproved" data have already updated their software and are prepared: even if BIP110 activates, they will be able to continue embedding similar data. Many of us predicted this in advance because it is fundamentally impossible to restrict how people interpret entries on an open, public ledger using external software.
In summary, BIP110 attempts to do the impossible—restrict how users of an open-access ledger can use it—while the problem it claims to address is already well-handled by Bitcoin's existing protocol limitations. It also seeks to force this through with an irresponsible short timeline, rushed code review, and a disregard for ecosystem consensus. Fortunately, Bitcoin is not such a fragile system; this reckless attempt at modification will not succeed.
Miners have already explicitly rejected BIP110, and developers, investors, KOLs, and the business community have voiced their 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.
