Michael Saylor: 110 Reasons to Oppose BIP-110

Author: saylor

Compiled by: Plain Blockchain

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

Many Bitcoin enthusiasts I represent support BIP 110. They desire verifiable liability accessibility, seek to protect node operators from the burden of excessive costs and content, maintain feasible payment fees, and aim to anchor Bitcoin to being a sound monetary currency rather than a generic data store. These are serious concerns, and I share these goals, but I disagree with the proposed solution.

This criticism is directed at the proposal itself, not the team behind it. I assume good faith from all involved. Bitcoin is strongest when we can engage in debate rather than treat fellow stakeholders as enemies.

This article also does not defend every inscription, token, file, or application. Some of these uses may be frivolous, harmful, or fraudulent. The core question is more specific: Should we modify consensus rules to address contentious uses stemming from transactions that are currently valid and have paid fees?

The reasons listed below are not all of equal weight, and several complement each other; the conclusion is cumulative and progressive.

The Content of the BIP 110 Proposal

This article addresses BIP 110 version 1.0.0, which was advanced to the "Complete" status on June 25, 2026. "Complete" merely means the author has finished their intended work and recommends implementation; it does not mean Bitcoin has adopted the proposal or that community consensus has been reached. The official BIPs repository explicitly states that publication does not indicate a proposal has good prospects, community will, or is imminent for adoption.

Upon activation for approximately one year, BIP 110 would add seven consensus limits: limit new scriptPubKeys to 34 bytes (with an exception allowing 83 bytes for OP_RETURN); limit many data-carrying witness stack items to 256 bytes; prohibit spending outputs with undefined witness versions and Tapleaf versions (while still allowing creation of such outputs); prohibit the use of Taproot annexes (the annex); limit Taproot control blocks to 257 bytes; reject Tapscripts containing OP_SUCCESSx opcodes; and reject Tapscripts that execute OP_IF or OP_NOTIF.

The proposal includes a grandfather clause (carve-out) for unspent transaction outputs (UTXOs) created before activation, an important safety measure. I am not claiming BIP 110 would broadly confiscate existing bitcoins. My objection is more precise: it restricts the functionality of currently valid transactions, potentially affecting rare pre-signed workflows that cross the activation boundary, where technical alternatives exist, and sets a precedent of using consensus limits to target specific categories of use.

BIP 110 also proposes a modified BIP 9 deployment method: using 55% miner signaling threshold (compared to 95% for BIP 9); removing the traditional timeout and FAILED state; adding a mandatory signaling period; ensuring lock-in occurs on-chain no later than a specified height; and adding an EXPIRED state after 52,416 active blocks. (GitHub)

Like any soft fork, BIP 110 is not imposed by a central authority. Users choose which software and rules to run. Risk arises when economically significant participants enforce materially different rules, leading to pressure, uncertainty, or a chain split.

The author provides a reference implementation, test vectors, detailed rationale, and frank discussion of trade-offs—these are proper merits of the document. The proposal argues that urgency and temporary duration justify lower thresholds and intentionally blunt restrictions. I respect this care and work, but I disagree with their risk assessment logic. (GitHub)

I. Neutrality and Foundational Principles

1. Consensus is Bitcoin's most powerful intervention mechanism. A soft fork renders blocks valid under old rules invalid in the eyes of upgraded nodes. This power should be reserved for addressing clear, severe, and widely understood system failures.

2. It is not a fix for a proven failure. BIP 110 does not fix signatures, validation, double-spending, or a known critical vulnerability. It addresses contentious externalities and use cases, so the burden of proof should be extremely high.

3. It elevates contentious value judgments into protocol law. This proposal moves debates about legitimate uses and externalities from node policy, mining policy, and market games into consensus itself.

4. Bitcoin cannot recognize intent. The network cannot discern whether bytes represent an image, a proof, a contract, metadata, a record of authenticity, or a future innovative application.

5. Proxies based on structure carry collateral damage risk. Because intent cannot be identified, restricting technical forms will simultaneously block illegitimate and legitimate uses.

6. Social signaling must not become grounds for consensus change. The specification explicitly frames activation as a way to express "unwelcomeness to data storage." Consensus changes should be based on compelling technical or monetary arguments, not primarily to express displeasure. (GitHub)

7. Objectionability is not invalidity. Even if a transaction is trivial, speculative, objectionable, or wasteful, it remains valid if it obeys the rules and pays the required resource fee.

8. It narrows the economic freedom on the BIP 110 chain. While pre-activation UTXOs are grandfathered, users creating new UTXOs after activation will find their legitimate ways to construct and spend transactions restricted from inception.

9. A permissionless system must accept unapproved exploration. Requiring innovators to prove their use case's value before building contradicts the essence of permissionless innovation.

10. It inverts protocol conservatism. Conservatism at the base layer should mean caution in modifying consensus, not eagerness to modify consensus to enforce a particular application philosophy.

II. Failure to Meet the Burden of Proof

1. "Spam" is not a computational primitive. No operation can distinguish spam from utility; these labels originate from human value judgments.

2. "Monetary" and "non-monetary" cannot be cleanly separated. Payment channels, proof of reserves, covenant escrows, smart contracts, or settlement commitments are both financial activities and data.

3. Known scenarios do not represent the full design space. Protecting all known monetary uses is a useful data point, but the nature of innovation lies in the undiscovered.

4. The BIP itself does not quantify the node burden it aims to eliminate. It describes costs but provides no related metrics for increased bandwidth, storage, validation load, labor proportion, or potential node loss/churn.

5. It does not quantify the decentralization benefit. Assertions that BIP 110 will improve decentralization are made without a quantifiable model or target.

6. It does not demonstrate expected fee relief. The proposal does not indicate by how much transaction fees would drop, for how long, or how many users would benefit from lower commission costs.

7. UTXO set inflation, initial sync bandwidth, archival storage, relay load, and validation time are different concerns that may require different solutions.

8. "Urgency" remains an assertion without an operational definition. It cites an urgent, crisis-like situation but provides no measurable threshold for what triggers a crisis.

9. Historical node policy limits are not proof of consensus wisdom. An 83-byte default can be a practical node policy but should not be directly elevated to eternal block validity rules.

10. The 256-byte cutoff is arbitrary. Its rationale partly references image compression sizes and large cryptographic integers but fails to prove 256 bytes is the optimal boundary between safety and innovation. (GitHub)

III. Technically Overly Broad

1. Seven separate consensus changes are bundled together. Participants might support one limit but reject another, yet they must accept or reject the entire package.

2. The strongest technical concern is bundled with unrelated restrictions. Oversized scriptPubKeys increase UTXO set size and verification. If this poses a measurable risk, it should be proposed as a precise, standalone change, not automatically accompanied by six other limits. (GitHub)

3. The 83-byte OP_RETURN policy is elevated to consensus. This turns a configurable relay and mining preference into a block validity rule.

4. The 256-byte limit restricts a generic primitive. It aims to target data storage by limiting broad individual data-carrying witness stack items.

5. Spending undefined witness and Tapleaf versions is banned. These spaces are currently in use partly because they are reserved for future upgrades.

6. Taproot annexes (the annex) are banned. BIP 341 designed the annex for future extension. Even if users should not use it before its implications are clear, closing a deliberately considered upgrade path requires extraordinary justification. (GitHub)

7. Taptree depth is curtailed. The 257-byte control block limit restricts revealed scripts to 7 layers, hampering complex script tree structures.

8. OP_SUCCESSx is banned even in unexecuted branches. BIP 342 created these opcodes as clear upgrade hooks for future soft forks. (GitHub)

9. Executed OP_IF and OP_NOTIF in Tapscript are prohibited. The author argues they are often used for data carving but also acknowledges their value for experimental uses and Miniscript efficiency.

10. The proposal admits sacrificing precision for speed. Its rationale states that a more balanced approach would require more development and review, therefore choosing intentionally blunt limits for quick deployment. Urgency must not excuse imprecise consensus code. (GitHub)

IV. Sacrifices Compatibility and Future Optionality

1. It shuts down multiple upgrade paths at once. Annexes, future witness versions, future Tapleaf versions, and OP_SUCCESSx are part of Bitcoin's intentional design space. (GitHub)

2. Reservation does not imply uselessness. It means early designers thoughtfully preserved options for needs not yet apparent.

3. The author's one-year ban could still disrupt development timelines. A future soft fork likely needs more than a year to coordinate, but this is an estimate, not a guarantee.

4. It could complicate designs like BitVM. The specification itself acknowledges the control block limit could hinder advanced off-chain covenant designs.

5. It could affect Miniscript-generated Taptrees. The proposal acknowledges compiler outputs may contain OP_IF, requiring adjustment.

6. It forces wallet tools to change. The well-formedness section notes that during the period rules must be effective, Miniscript compilers must adapt.

7. It introduces minor but acknowledged capital access risk. The BIP frankly mentions rare pre-signed Taproot scenarios where UTXOs created after activation could be locked or unexpectedly consumed.

8. While pre-activation UTXOs are fully protected, workflows that create or spend related outputs during the deployment period will still face new constraints.

9. It suggests migrating potentially stranded funds. Asking some users to migrate funds carries non-zero friction.

10. "No known scenario" is not proof of safety. Private systems, undisclosed contracts, experimental wallets, and future protocols are not fully observable. (GitHub)

V. Temporary Consensus Rules Still Add Inherent Complexity

1. Temporary consensus code is still consensus code. It must be specified, implemented, reviewed, tested, deployed, monitored, and decommissioned.

2. Grandfather clauses create full dependency on state history. Two identical constructs may be treated differently solely based on when their UTXO was created.

3. Rules dependent on state history add implementation complexity. Each implementation must accurately identify UTXO creation height and apply carve-out rules completely consistently.

4. Activation creates a critical boundary. Software and economic participants must agree on when new restrictions become active.

5. Expiration creates another boundary. They must also agree on when restrictions end and what behavior becomes valid again.

6. BIP 110 adds a new Expired state. This extends the familiar deployment state machine with new consensus behavior.

7. It removes the traditional FAILED exit. The proposed deployment cannot simply time out and fail like regular BIP 9.

8. It creates multiple coordination windows. Voluntary signaling, mandatory signaling, lock-in, activation, and expiration—each introduces the possibility of divergence. (GitHub)

9. Temporary rules may leave permanent scars. Wallet code, operational processes, contracts, and institutional risk controls may need modification lasting beyond the deployment period.

10. More state transitions mean a larger attack surface. Test vectors reduce known risks but cannot enumerate every unexpected edge-case scenario.

VI. Economic and Security Effects Are Uncertain

1. Node externalities are real but vary by node type. Full validation nodes must download and verify blocks, while pruning nodes can discard old raw block data and limit historical storage. Relevant costs should be disaggregated. (Bitcoin Core)

2. The fee appropriation problem is not unique to data transactions. Miners collect fees, while validators bear costs for every transaction. While the magnitude may differ, the basic misalignment is consistent.

3. Technical costs should be priced directly. For a given data volume and verification work, resource costs come from bytes, state, computation, and bandwidth, independent of whether an observer endorses the transaction's purpose.

4. BIP 110 cannot eradicate data embedding. The specification itself admits users can split data into smaller pieces or disguise it within permitted structures. (GitHub)

5. Workarounds could further reduce transaction efficiency. Fragmentation or obfuscation consumes more structural resources, increasing analysis complexity, without eliminating underlying demand.

6. Suppressing one use may lower fee pressure but could also reduce total fee revenue or shift demand to other encodings, or all three.

7. The importance of fee revenue grows as block rewards decline. Transaction fees supplement block rewards, which halve every 210,000 blocks. (Bitcoin Developer Documentation)

8. A net decrease in fee demand could marginally impact security. If BIP 110 reduces total fee demand rather than reallocating it, ceteris paribus, lower miner revenue could marginally affect hash power investment.

9. Diverse demand can strengthen fee market resilience. Payments, channels, custody systems, financial apps, and other uses need not peak simultaneously.

10. The proposal does not model the security trade-off. It promises cheaper payments and reduced node costs but does not quantify potential impacts on miner revenue, hash power investment, or long-term fee market depth.

VII. Better Market and Policy Tools Exist

1. Bitcoin already has a content-neutral capacity limit. Block weight imposes a general limit on chain transaction capacity. (GitHub)

2. Fees already price scarce block space. Users bid according to urgency, and miners select valid transactions based on their own policies.

3. Block limits and fee markets do not require users to declare purpose. They apply technical validity and resource constraints, not semantic review of whether a transaction is sufficiently "monetary".

4. Relay policy is a gentler tool. Implementations and node topologies can autonomously choose which unconfirmed transactions to relay, without redefining what constitutes a valid block. Bitcoin Core's data carrier policy is configurable. (GitHub)

5. Miners can exclude certain transaction classes from their block templates, without forcing all validating nodes to reject blocks containing such transactions.

6. Policies are imperfect, but imperfection does not equal failure. Direct transaction submission to miners can bypass relay filters. This limitation merits analysis, not an immediate leap to outright prohibition.

7. No transaction has an absolute right to be included. Miners can reject it based on their own policy, but making a currently valid transaction invalid via a fork is a qualitatively different step.

8. Resource pricing can be improved without distinguishing purpose. If certain structures impose disproportionate costs, Bitcoin can research content-neutral limits or pricing mechanisms directly tied to measurable resource consumption.

9. Optional data and pruning designs deserve continued research. They may not address all concerns but are more directly targeted at storage burdens than rules aimed at expressing unwelcomeness to certain purposes.

10. The BIP itself acknowledges policy is usually the right arena for spam defense. Imperfect filtering by policy does not inherently justify resorting to consensus. (GitHub)

VIII. Chills Innovation and Network Adoption

1. It creates a chilling effect. If currently valid constructs can be disabled via consensus to suppress associated uses, developers may choose to build elsewhere.

2. It privileges incumbency. "Protecting all known monetary uses" protects the past, not the future.

3. It destroys option value before value discovery. The future's best use for an upgrade hook may not even have a name today.

4. Sound infrastructure is crucial for long-term commitments. Wallets, custody systems, payment channels, and financial protocols need trust that valid transaction structures will remain available.

5. It shrinks the design space for covenants. This may force certain constructions to be larger, more expensive, less elegant, or impossible to construct within given constraints.

6. It could delay advanced covenant research. The BIP explicitly accepts that work like BitVM may need to wait or proceed only on testnets and sidechains. (GitHub)

7. It banishes experimentation from Bitcoin via consensus. Testnets and sidechains are useful, but builders should not be evicted from the base layer without overwhelming safety reasons.

8. Future layer-2 systems may rely on hooks that are used for carving today. Optionality at the base layer can support scaling without requiring coordinated layer activity.

9. Applications can reinforce monetary properties. Better wallets, custody, settlement, credit, securities, and proof systems can enhance Bitcoin's utility, liquidity, and demand.

10. Bitcoin does not have to choose between "money" and "technology." Its monetary strength can be further solidified by being an open network supporting secure wallets, covenants, custody, settlement, and innovation.

IX. Activation Warnings

1. The 55% threshold is a major departure from BIP 9. BIP 9 stipulates a 95% miner threshold, whereas BIP 110 proposes 55%.

2. Controversial content-limiting soft forks demand higher confidence, not lower. Temporary duration does not make coordination failure harmless.

3. Miner signaling does not represent all Bitcoin users. Hash power secures and orders transactions, but exchanges, wallets, businesses, custodians, and enterprises decide which rules and assets they accept economically.

4. The mandatory signaling period alters non-participation's signal. During a specified window, nodes enforcing the new rules will reject blocks not signaling bit 4.

5. The deployment aims for lock-in on-chain no later than a predetermined height. This is more forceful than merely observing voluntary signal state.

6. The lack of a FAILED state removes a clean exit path. A proposal failing to attract sufficient voluntary support should be able to expire gracefully without forced coordination. (GitHub)

7. Activation mechanisms do not produce consensus. They can coordinate software state, but cannot produce consensus in the social and economic dimensions.

8. Aggressive enforcement could lead to network splits. If economically significant participants enforce materially incompatible validity rules, the result could be a chain split or prolonged uncertainty.

9. Temporary splits are not trivial. Liquidity, custody, settlement, accounting, and user confidence can all be affected.

10. Hard forks are Bitcoin's immune system. Lowering the barrier to contentious use-case limiting soft forks may pose risks greater than the targeted data storage issue itself.

X. The Precedent Set Is More Dangerous Than the Target

1. Rules will sunset, but precedent endures. Future campaigns can cite BIP 110 as an example, claiming consensus can be used to suppress unpopular legitimate activities.

2. One faction could label another use as non-monetary, dead, legally risky, or unsupported and seek to exclude it.

3. "Unsupported use" is an infinitely expandable category. Bitcoin has no central product manager to permanently define its approved scope.

4. Technical boundaries will morph into political ones. Once reliant on value judgments about legitimate purpose, protocol debates transform into contests of values and power.

5. Today's targeted limit is not tomorrow's target. Privacy tools, novel custody, stablecoin settlement, token systems, corporate uses, or other unpopular applications could face similar reasoning. This is not a prediction; it is a governance risk.

6. Every limit is presented as special at the time. Precedents are created because advocates believe their case is unique.

7. Social cohesion is a scarce asset. Exhausting it on cultural fights depletes the trust and negotiating capacity needed for more severe threats.

8. Every stakeholder deserves consideration. Developers, node operators, miners, holders, wallets, exchanges, custodians, companies, and institutions bear different risks and responsibilities.

9. Risk-bearing capital should be considered but does not grant absolute control. Large holders, miners, exchanges, custodians, and companies do not own consensus. Individual developers or node operators do not either. Robust consensus requires coordination among all participants.

10. Corporate participation in strengthening Bitcoin is legitimate. Companies operate at scale with regulation, volatility, capital, and incentives. They should not wield veto power, but neither should they be treated as outsiders to this global monetary network.

XI. A Better Path Exists

1. Participants can oppose data storage without modifying consensus. They can choose to not use, not promote, not index, not relay, and not mine it.

2. Stricter software preferences should remain voluntary. Competing implementations and configurable policies are features of an open network, not bugs.

3. We can improve measurement before governance. Publish reproducible data on bandwidth, storage, validation times, UTXO growth, fee incidence, and node economics.

4. We can target measurable resource costs precisely. A narrowly tailored rule linked to a demonstrated denial-of-service or validation risk is more defensive than a broad rule bundled with a general-purpose ban.

5. We can improve how data is stored. Better caching mechanisms, optional storage, pruning, and layer-2 architectures can reduce burden while preserving functionality.

6. We can enhance fee market transparency. Better tools and models can show who is paying, who bears costs, and which uses truly crowd out payments.

7. We can preserve upgrade hooks while continuing research. Unused capacity reserved to protect future soft-fork paths is not necessarily waste.

8. We can wait for overwhelming consensus support. The cost of waiting should be weighed against the cost of an unnecessary fork. In the absence of compelling evidence of emergency and broad consensus, restraint is the safer choice.

9. We can protect rebels without turning the White House into the enemy. BIP 110 supporters are trying to protect Bitcoin. Respecting them means addressing their concerns while rejecting a cure that creates a larger problem.

10. BIP 110 would employ consensus to narrow legitimate activity, limit future optionality, increase deployment complexity, and set a precedent that cannot be un-set. It would be a "Bitcoin iatrogenic proposal."

Guardians of Neutrality

Bitcoin's genius is that not everyone agrees on every use. Its genius is that it is constrained by neutral rules and hard consensus.

Fees price block space. Node choice and policy signal votes. Miners build the chain. Consensus allocates capital. Developers propose code. Companies build infrastructure and applications. Protocol changes should only prevail when they enhance security, utility, and achieve overwhelming consensus.

This article does not defend every inscription, token, file, or application. It is a defense of neutral rules—rules that keep Bitcoin open and allow markets to reward what is useful and discard what is not.

Bitcoin should, by its nature, be conservative. To me, this means rejecting BIP 110.

Bitcoin does not need redeeming guardians.

It needs guardians of neutrality.