Translation: Plain Language Blockchain

Reconstructing Neutral Rules, Hard Consensus, Open Markets, and Permissionless Innovation

Many Bitcoin enthusiasts I represent support BIP 110. They wish to verify debt accessibility, address the concerns of node operators regarding necessary costs and content, maintain viable payment fees, and keep Bitcoin fixed to a stable currency rather than a common data storage. These are serious concerns, and I support these goals, but I disagree with the solutions proposed.

The criticism here is directed at the initiative itself, not the team behind it. I assume everyone is acting in good faith. Bitcoin is most powerful when we can debate rather than cast the alliance as an enemy.

This article does not defend every type of inscription, token, document, or application. Some of these uses may be frivolous, harmful, or fraudulent. The core of the issue is clearer: Should the current and valid payment transaction platform disputes be resolved through modifications?

The reasons listed below do not carry equal weight, and there are several that complement each other, leading to a conclusion that is cumulatively progressive.

Proposal Content of BIP 110

This article addresses BIP 110 version 1.0.0, which was advanced to "Complete" status on June 25, 2026. "Complete" merely indicates that the author has finished the anticipated work and recommends implementation, not that Bitcoin has adopted the proposal or that consensus has been reached within the community. The official BIP code repository clearly states that publication does not represent a proposal having good channel access or community willingness, nor is it about to be adopted.

During its approximately one-year effectiveness, BIP 110 will introduce seven opinion restrictions: it will set the new script PubKey to 34 bytes (with OP_RETURN using an 83-byte exception); limit various anesthetic and script restriction parameters for witness items to 256 bytes; prohibit the use of undefined witness versions and Tapleaf versions (though still create outputs that allow for such use); ban the use of Taproot auxiliary areas; keep the Taproot control block within 257 bytes; reject Tapscript that includes OP_SUCCESSx bytecode; and deny the execution of OP_IF or OP_NOTIF in Tapscript.

The proposal implements grandfather clauses (carried forward) for unspent transactions (UTXO) created prior to activation, which is an important safeguard. I am not arguing that BIP 110 will broadly confiscate existing bitcoins. My opposition is more precise: it expands the current effective transaction functionalities at a level, which may impact the rare pre-signed workflows across activation periods, where there are technical choices available, and establishes a precedent for prioritizing restrictions against specific categories of usage.

BIP 110 also proposes a modified BIP 9 deployment method: employing 55% miner signaling for account expression (compared to the 95% requirement in BIP 9); removing traditional timeout and FAILED states; adding a mandatory signaling expression period; ensuring chain execution is locked no later than the specified height; and adding an EXPIRED (latest) status after 52,416 active blocks.

Like any soft fork, BIP 110 is not imposed by a central authority. Users can choose their payment software and rules. When economically influential participants execute rules that differ materially, risks arise, leading to stress, uncertainty, or a split in the chain.

The author provides reference implementations, testing alerts, detailed reasonable explanations, and an honest discussion of trade-offs, which are reasonable merits of this document. The proposal implies that urgency and a temporary deadline grant lower volume and intentions that are bluntly restrictive. I respect this concern and effort, but I disagree with their risk assessment logic.