Note: BIP-110 is the most contentious protocol proposal currently under debate in the Bitcoin community. $Strategy (MSTR.US)$ Founder Michael Saylor recently published an extensive article outlining 110 reasons against it. The full translation is provided below for readers’ reference. The views expressed herein do not represent those of Jiaolian. Consider multiple perspectives to gain clarity.
Original Title: 110 Reasons BIP-110 Is a Bad Idea
Subtitle: A case for neutral rules, hard consensus, open markets, and permissionless innovation
Publication Date: July 19, 2026
110 Reasons Why BIP-110 Is a Bad Idea
Author: Michael Saylor
An argument concerning neutral rules, hard consensus, open markets, and permissionless innovation
I respect many of those who support BIP-110. $Bitcoin (BTC.CC)$ They aim to preserve accessibility for validation, protect node operators from unnecessary costs and externalities, maintain affordable payments, and keep Bitcoin focused on sound money rather than general-purpose data storage. These are legitimate concerns. I share these objectives—but I disagree with this proposed solution.
This article critiques the proposal itself, not the people behind it. I assume they act in good faith. Bitcoin’s greatest strength lies in our ability to disagree vigorously without mistaking allies for enemies.
Nor does this article defend every inscription, token, file, or application. Some may indeed be frivolous, harmful, or fraudulent. The issue is narrower: should a controversial yet currently valid paid transaction use case be addressed by changing consensus?
Each of the following arguments carries varying weight, and some reinforce one another. The case is cumulative.
BIP-110 Proposal Content
This article discusses version 1.0.0 of BIP-110, titled 'Reduced Data Temporary Softfork,' which was advanced to 'Complete' status on June 25, 2026. According to BIP 3, 'Complete' means the author has finished the planned work and recommends adoption. This does not imply that Bitcoin has adopted the proposal or that community consensus has been reached. The BIP repository explicitly states that publication does not indicate the proposal is sound, enjoys community consensus, or is imminent for adoption.
During its approximately one-year effective period, BIP-110 would introduce seven new consensus restrictions: limiting new scriptPubKeys to 34 bytes (with an exception of 83 bytes for OP_RETURN); capping most pushed payloads and script-argument witness items at 256 bytes; prohibiting spending outputs with undefined witness versions and Tapleaf versions (while still allowing the creation of such outputs); banning Taproot annexes; restricting Taproot control blocks to 257 bytes; rejecting Tapscripts containing OP_SUCCESSx opcodes; and rejecting execution of Tapscripts that include OP_IF or OP_NOTIF.
The proposal includes a grandfathering clause protecting unspent transaction outputs (UTXOs) created before activation. This is an important safeguard. I do not claim that BIP-110 would result in large-scale confiscation of existing bitcoins. My objection is narrower: it prospectively removes currently valid transaction functionalities, potentially affecting rare pre-signed workflows that span the activation date, reducing technical optionality, and setting a precedent for using consensus changes to block an entire class of previously valid uses.
BIP-110 also proposes a modified BIP 9 deployment mechanism: adopting a 55% miner signaling threshold (instead of BIP 9’s 95%), eliminating the standard timeout and FAILED states, introducing a mandatory-signaling period, guaranteeing lock-in on-chain no later than a specified block height, and adding a new EXPIRED state after 52,416 active blocks.
Like any soft fork, BIP-110 is not enforced by a central authority. Users choose which software and rules to run. The risk lies in pressure, uncertainty, or chain splits arising when economically significant participants enforce materially different rule sets.
The authors provide a reference implementation, test vectors, detailed rationale, and candid discussion of trade-offs—significant strengths of the document. The proposal argues that urgency and its temporary nature justify lowering thresholds and intentionally implementing simple, coarse-grained restrictions. I respect this concern and effort, but I disagree with its risk assessment.
I. Neutrality and First Principles
Consensus is Bitcoin’s most powerful intervention mechanism. A soft fork renders blocks that were valid under prior rules invalid to upgraded nodes. This power should be reserved for clear, severe, and widely understood failures.
This is not a fix for an established consensus failure. BIP-110 does not address inflation, signature validation, double-spending, or any known critical vulnerability. Instead, it targets a contested externality and usage issue, thereby demanding an especially high burden of proof.
It elevates a contested judgment into a protocol rule. The proposal shifts disputes over legitimate use and externalities—from relay policy, mining policy, and market-level considerations—into the domain of consensus validity.
Bitcoin cannot read intent. The network cannot determine whether bytes represent an image, a proof, a contract, metadata, an attestation record, or a future application.
Structural proxies entail collateral risks. Because intent is unknowable, the proposal restricts technical constructs that may simultaneously serve undesirable and legitimate purposes.
Social signaling alone is insufficient grounds for a consensus change. The proposal explicitly frames activation as a communication tool indicating that data storage is unwelcome. Consensus changes should be driven by compelling technical or monetary reasons, not primarily to express disapproval.
Disapproval does not equate to invalidity. A transaction may be frivolous, speculative, offensive, or wasteful, but as long as it complies with the rules and pays the required fees, it should be included.
It narrows prospective economic freedom on the BIP-110 chain. UTXOs created before activation are grandfathered, but users who create UTXOs during the effective period will have fewer valid ways to construct and spend them compared to the current consensus rules.
Permissionless systems must tolerate unapproved experimentation. Requiring innovators to first prove the value of their use case before building inverts the very meaning of permissionless innovation.
It inverts protocol conservatism. Conservatism at the base layer should mean reluctance to alter consensus, not eagerness to modify consensus for the sake of a conservative philosophy of use.
II. The burden of proof has not yet been met.
‘Spam’ is not a consensus primitive. No opcode can distinguish spam from utility. These labels stem from human judgment.
‘Monetary’ and ‘non-monetary’ are not cleanly separable. Payment channels, proof of reserves, custody strategies, smart contracts, or settlement commitments are simultaneously financial activities and data.
Known use cases do not exhaust the entire design space. The proposal claims it preserves all known monetary use cases. By definition, innovation lies precisely in what has not yet been recognized.
The BIP itself does not quantify the node burden it intends to remove. It describes costs but provides no estimates of associated bandwidth, storage, validation load, hardware thresholds, or the projected number of node operators retained or lost.
It does not quantify decentralization gains. The claim that BIP-110 will improve decentralization lacks an accompanying quantifiable model or target.
It does not quantify payment cost reduction. It offers no estimate of how much transaction fees would decrease, for how long, or how many payment users would benefit.
It conflates distinct costs into a single diagnosis. UTXO state growth, initial sync bandwidth, archival storage, relay burden, and validation time each have different causes and may require different solutions.
Urgency is asserted, not operationally defined. The proposal declares the situation urgent—a crisis—but provides no objective threshold indicating when consensus intervention becomes necessary.
Historical relay policy limits are not evidence of optimal consensus constraints. The default value of 83 bytes may be a sound policy, but that does not make it an appropriate permanent block validity rule.
The 256-byte boundary is heuristic. The rationale links it to compressed image sizes and large cryptographic integers, but it does not demonstrate that 256 bytes represents the optimal trade-off between security and innovation.
III. Overly Broad Technical Scope
Seven distinct consensus changes are bundled together. Participants cannot support one restriction while rejecting another—they must accept or reject the entire package.
The most compelling technical concern is bundled with unrelated restrictions. Large scriptPubKeys could increase UTXO state size and validation costs. If this constitutes a measurable risk, it should be addressed in a separate, narrowly scoped proposal rather than being automatically tied to support for six other restrictions.
The 83-byte OP_RETURN policy becomes a consensus rule. This transforms a configurable relay and mining preference into a block validity rule.
The 256-byte limit constrains general primitives. It targets data storage by restricting broad categories of pushdata payloads and script parameter witness data.
Spending outputs with undefined witness versions and Tapleaf versions will be prohibited. These version spaces are unused today, partly because they have been reserved for future upgrades.
The Taproot annex will be disabled. BIP 341 reserves the annex for future extensions. Even though users should not use it before its semantics are defined, disabling an intentional upgrade path requires exceptional justification.
Merkle tree depth (Taptree depth) will be reduced. The 257-byte control block limit restricts revealable script paths to seven levels, potentially constraining complex script trees.
OP_SUCCESSx will be disabled even in unexecuted branches. BIP 342 introduced these opcodes specifically to serve as clean upgrade hooks for future soft forks.
Executed OP_IF and OP_NOTIF will be prohibited in Tapscript. The authors consider them redundant and frequently abused, though they acknowledge potential experimental uses and possible Miniscript efficiency gains.
The proposal openly trades roughness for speed. Its rationale states that achieving a better balance would require more development and review, so simpler restrictions were chosen to accelerate deployment. Urgency cannot substitute for the precision required in consensus code.
IV. Sacrificing Compatibility and Future Optionality
It closes multiple upgrade paths at once. Annexes, future witness versions, future Tapleaf versions, and OP_SUCCESSx are all part of Bitcoin’s reserved design space.
‘Reserved’ does not mean useless. It means early designers consciously preserved the option value for requirements that have not yet emerged.
Closing these paths for one year could still disrupt development timelines. The authors anticipate that future soft forks will require more than a year of coordination, but this is only an estimate, not a guarantee.
It may complicate BitVM-style designs. The proposal acknowledges that the control block size limit could hinder advanced off-chain contracting.
It may affect Miniscript-generated Tapleaves. The proposal acknowledges that certain compiler outputs might include OP_IF and would need adjustment.
It requires changes to affected wallet tools. The backward compatibility section notes that Miniscript compilers will need modifications during the period when the rule is active.
It creates a narrow but acknowledged risk to fund accessibility. BIP candidly identifies that in a limited set of pre-signed Taproot scenarios, UTXOs created after activation could be frozen or inadvertently spent.
Grandfathering provisions have value but do not provide complete insulation. UTXOs created prior to activation are protected, but workflows that create or spend affected outputs during deployment may still encounter new constraints.
Users are advised to migrate potentially affected funds. A proposal requiring even a narrow subset of users to migrate is not a zero-cost filter.
‘No known use cases’ is not a proof of safety. Private systems, undisclosed contracts, experimental wallets, and future protocols are not fully observable.
V. Temporary Consensus Rules Still Introduce Real Complexity
Temporary consensus code remains consensus code. It must be specified, implemented, reviewed, tested, deployed, monitored, and eventually retired.
Grandfathering provisions make validity historically dependent. The same spending construction may be treated differently depending on when the UTXO was created.
Historically dependent rules increase implementation complexity. Every implementation must identify the relevant UTXO creation height and apply the exemption consistently.
Activation creates a critical boundary. Software and economic participants must agree on when the new restrictions take effect.
Expiration creates another. They must also agree on when the restrictions end and when previously restricted behaviors become permissible again.
BIP-110 introduces a new expired state (EXPIRED). This extends the familiar deployment state machine and introduces new consensus behavior.
It removes the conventional failed state (FAILED). Proposed deployments cannot simply time out as in standard BIP 9.
It creates multiple coordination windows. Voluntary signaling, mandatory signaling, lock-in, activation, and expiration each introduce potential points of divergence.
Temporary rules may leave permanent traces. Wallet code, operational procedures, contracts, and institutional risk controls may require changes that persist beyond the deployment period.
More consensus forks imply a larger attack surface. Test vectors mitigate known risks but cannot exhaustively cover every private or future interaction.
VI. Economic and Security Impacts Are Uncertain
Node externalities are real but heterogeneous. Every full validating node must download and verify blocks, whereas pruned nodes can discard old raw block data and limit historical storage. Associated costs should be measured separately. (Bitcoin Core)
The fee recipient problem is not unique to data transactions. Miners collect fees, while validators bear part of the cost. The magnitude may differ, but the underlying structure is universal.
Technical costs should be measured directly. For a given amount of data and verification work, resource costs stem from bytes, state, computation, and bandwidth—not from whether observers agree with the transaction’s purpose.
BIP-110 cannot eliminate data embedding. The proposal acknowledges that users can split data or disguise it within permitted structures.
Avoidance may reduce transaction efficiency. Fragmented or ambiguous encodings could consume more structure and increase analytical complexity without eliminating underlying demand.
The fee impact is ambiguous. Suppressing one use case might lower payment fees, reduce total fee revenue, shift demand to other encodings, or a combination of all three.
Miner revenue becomes increasingly important as subsidies decline. Transaction fees constitute a component of block rewards, and the block subsidy halves every 210,000 blocks. (Bitcoin Developer Docs)
Lower aggregate fee demand marginally weakens security. To the extent that BIP-110 reduces total fee demand—rather than merely reallocating it—lower miner revenue diminishes incentives for hash rate investment, all else being equal.
Diverse demand sources can enhance the resilience of the fee market. Payments, channels, custody systems, financial applications, and other uses do not need to peak simultaneously.
The proposal does not model the security tradeoff. It advocates for cheaper payments and lower node costs but fails to estimate potential impacts on miner revenue, hash rate investment, or long-term fee market depth.
VII. Better Market and Strategic Tools Exist
Bitcoin already has a content-neutral capacity limit. Block weight imposes a uniform constraint on transaction capacity per block.
Fees already ration scarce block space. Users signal urgency through bidding, and miners select valid transactions according to their own strategies.
Block limits and the fee market do not require users to declare transaction purpose. They apply technical validity and resource constraints rather than semantic tests regarding whether a transaction is 'sufficiently monetary.'
Relay policy remains a weakly enforced tool. Implementations and node operators can choose which unconfirmed transactions to relay without redefining what constitutes a valid block. Bitcoin Core’s data carrier policy is configurable.
Mining policy remains voluntary. Miners can exclude certain types of transactions from their own block templates without forcing every validating node to reject blocks that include them.
Policy is imperfect, but imperfection does not equate to failure. Submitting transactions directly to miners can bypass relay filters. This limitation warrants analysis but does not automatically justify jumping to consensus-level prohibition.
No transaction has an inherent right to inclusion. Miners may reject a transaction based on their own policies, but invalidating previously valid transactions via a fork is a far more consequential action.
Resource pricing can be improved without categorizing transaction types. If certain structures impose disproportionate costs, Bitcoin could explore content-neutral limits or pricing mechanisms tied to measurable resource usage.
Pruning and optional data designs warrant continued research. They may not solve all problems, but they address storage burdens more directly than a rule partly intended to signal that 'a particular use case is unwelcome.'
The BIP itself acknowledges that policy is generally the appropriate venue for combating spam. The inability to guarantee perfect filtering does not in itself justify resorting to consensus rules.
VIII. Suppressing Innovation and Adoption
It creates a chilling effect. If currently valid transaction constructs can be suspended via consensus to suppress associated use cases, developers may avoid building on Bitcoin.
It favors existing use cases. 'All known monetary use cases' is about preserving the status quo rather than embracing the future.
It destroys the option value before that value is realized. The optimal future use of an upgrade hook may not yet have a name.
A stable foundation is critical for long-term contracts. Wallets, custody systems, payment channels, and financial protocols need confidence that effective transaction structures will remain available.
It narrows the script design space. This could render certain constructs larger, more expensive, less elegant, or temporarily infeasible.
It may delay advanced contract research. The BIP explicitly acknowledges that BitVM-style work may need to wait or be conducted on testnets and sidechains.
It pushes experimentation beyond Bitcoin through consensus. Testnets and sidechains are useful, but without compelling security justifications, builders should not be driven away from the base layer.
Future Layer 2 systems may rely on hooks unused today. Optionality at the base layer can support scaling without requiring frequent base-layer activity.
Applications can enhance money. Better wallets, custody, settlement, credit, securities, and proof systems can increase Bitcoin’s utility, liquidity, and demand.
Bitcoin does not have to choose between being money and being technology. An open network that supports secure wallets, contracts, custody, settlement, and innovation can strengthen its monetary power.
IX. The activation mechanism is overly aggressive
The 55% threshold represents a significant departure from BIP 9, which specifies a 95% miner readiness threshold; BIP-110 proposes 55%.
Controversial restrictions should require higher confidence, not lower. Temporary deadlines do not render coordination failures harmless.
Miner signaling is not a referendum of all Bitcoin users. Hash rate secures and orders transactions, but holders, exchanges, wallets, merchants, custodians, and enterprises determine which rules and assets they economically accept.
Mandatory signaling changes the meaning of non-participation. Within the designated window, validating nodes will reject blocks that do not signal with bit 4 set.
This deployment is designed to lock in on the execution chain no later than the predetermined block height. This is more forceful than merely observing voluntary readiness.
The absence of a FAILED state eliminates a clean exit path. A proposal that fails to attract sufficient voluntary support should be allowed to expire without forced coordination.
An activation mechanism cannot create consensus. It can coordinate software states, but it cannot generate social or economic consensus.
Divergent enforcement may split the network. If economically significant participants apply incompatible validity rules, the result could be a chain split or prolonged uncertainty.
A temporary split would not be trivial. Liquidity, custody, settlement, accounting, and user confidence could all be adversely affected.
Hard consensus is Bitcoin's immune system. Lowering the threshold for a controversial use case could be more dangerous than the data storage issue it aims to address.
X. Precedent Is More Dangerous Than the Objective
Rules expire, but precedents do not. Future movements can cite BIP-110 as evidence that consensus can be used to suppress valid activities deemed undesirable.
The same logic can be reused. A faction could label another use case as non-monetary, harmful, legally risky, or unsupported, and seek to exclude it.
‘Unsupported uses’ constitute an expandable category. Bitcoin has no central product manager to permanently define its scope of approved applications.
Usage-based boundaries become political boundaries. Once validity hinges on judgments about legitimate uses, protocol debates turn into contests over values and power.
Today’s targets cannot constrain tomorrow’s. Privacy tools, novel custody models, stablecoin settlements, token systems, enterprise applications, or other disfavored uses may face similar arguments. This is not a prediction—it is a governance risk.
Every restriction is presented as an exception. Precedents are precisely created by cases that their advocates consider unique.
Social cohesion is a scarce asset. Encoding cultural controversies into consensus may deplete the trust and coordination capacity needed to address more severe threats.
Every stakeholder deserves to be heard. Developers, node operators, miners, holders, wallet providers, exchanges, custodians, companies, and institutions each bear distinct risks and responsibilities.
Capital at risk merits consideration but must not be granted control. Large holders, miners, exchanges, custodians, and companies do not own consensus—nor do developers or node operators acting alone. A durable protocol requires coordination among all parties.
Corporate participation is legitimate when it strengthens Bitcoin. Companies enable people to organize within legal frameworks, offering scale, accountability, capital, and continuity. They should neither hold special authority nor be treated as outsiders to a global monetary network.
XI. There Exists a Better Path
Participants can oppose data storage without altering consensus. They can refuse to use, promote, index, relay, or mine it.
Stricter software choices can remain voluntary. Competing implementations and configurable policies are features—not flaws—of open networks.
We can improve measurement before intervening. Publish reproducible data on bandwidth, storage, validation time, UTXO growth, fee displacement, and node economics.
We can target measurable resource costs. A narrow rule—tied to demonstrated denial-of-service or validation risks—is more defensible than a broad bundle partially linked to perceived utility.
We can improve data placement. Better commitments, optional storage, pruning, and Layer 2 architectures can reduce burdens while preserving functionality.
We can enhance fee market transparency. Improved tools and models can illustrate who pays, who bears the costs, and which uses actually crowd out payments.
We can retain upgrade hooks while research continues. Unused capacity is not necessarily wasted when safeguarding future soft fork pathways.
We can wait for overwhelming consensus. The cost of waiting should be weighed against the cost of unnecessary forks. In the absence of compelling evidence of urgency and broad consensus, restraint is the safer default.
We can disagree without turning allies into enemies. Supporters of BIP-110 are trying to protect Bitcoin. A respectful response addresses their concerns while rejecting a solution that creates greater risks.
110. The proposed cure is more dangerous than the disease. BIP-110 would use consensus to narrow valid activity, constrain future options, complicate deployment, and establish a precedent it cannot erase. This makes it a Bitcoin Iatrogenic Proposal.
Guardians of Neutrality
Bitcoin’s strength does not lie in universal agreement on every use case. Its strength lies in the fact that disagreements are bounded by neutral rules and hard consensus.
Fees price block space. Nodes select policies and validate consensus. Miners construct blocks. Holders allocate capital. Developers propose code. Companies build infrastructure and applications. Protocol changes should only succeed when there is overwhelming alignment across validation, security, utility, and capital.
This is not a defense of every inscription, token, file, or application. It is a defense of neutral rules—rules that keep Bitcoin open, allowing the market to reward what is useful and discard what is not.
Bitcoin should remain conservative at the base layer. To me, this means rejecting BIP-110.
Bitcoin does not need guardians of purity.
It needs guardians of neutrality.