A case for neutral rules, hard consensus, open markets, and permissionless innovation
Many Bitcoiners I respect support BIP 110. They want to keep validation accessible, protect node operators from unwanted costs and content, preserve affordable payments, and keep Bitcoin focused on sound money rather than general-purpose data storage. Those are serious concerns. I share the objectives. I disagree about the remedy. (GitHub
This article critiques the proposal, not the people behind it. I assume good faith. Bitcoin is strongest when we can disagree vigorously without mistaking allies for enemies.
Nor is this a defense of every inscription, token, file, or application. Some may be frivolous, harmful, or fraudulent. The question is narrower: should a disputed use of currently valid, fee-paying transactions be addressed by changing consensus?
Not every reason below carries equal weight, and several reinforce one another. The case is cumulative.
What BIP 110 Proposes
This article addresses BIP 110 version 1.0.0, the “Reduced Data Temporary Softfork,” advanced to Complete on June 25, 2026. Under BIP 3, Complete means the authors have concluded their planned work and recommend adoption. It does not mean Bitcoin has adopted the proposal or that the community has reached consensus. The BIPs repository explicitly states that publication does not establish that a proposal is good, has community consensus, or is about to be adopted. (GitHub
During an approximately one-year active period, BIP 110 would add seven consensus restrictions. It would limit new scriptPubKeys to 34 bytes, with an 83-byte exception for OP_RETURN; limit many pushed payloads and script-argument witness items to 256 bytes; prohibit spending undefined witness and Tapleaf versions while still allowing such outputs to be created; prohibit the Taproot annex; cap Taproot control blocks at 257 bytes; reject Tapscripts containing OP_SUCCESSx opcodes; and reject Tapscript executions of OP_IF or OP_NOTIF. (GitHub
The proposal grandfathers unspent transaction outputs created before activation. That is an important safeguard. I do not claim that BIP 110 broadly confiscates existing bitcoin. My objection is narrower: it prospectively removes currently valid transaction functionality, can affect rare pre-signed workflows that span activation, reduces technical optionality, and establishes a precedent for using consensus restrictions to discourage a category of otherwise valid use. (GitHub
BIP 110 also proposes a modified BIP 9 deployment. It uses a 55 percent miner-signaling threshold, compared with the 95 percent threshold specified in BIP 9; eliminates the conventional timeout and FAILED state; adds a mandatory-signaling period; guarantees lock-in on the enforcing chain no later than a specified height; and adds a new 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 enforce. The risk arises when economically significant participants enforce materially different rules, creating pressure, uncertainty, or a chain split.
The authors provide a reference implementation, test vectors, a detailed rationale, and a candid discussion of tradeoffs. Those are substantive strengths of the document. The proposal argues that urgency and temporary duration justify the lower threshold and intentionally simple, blunt restrictions. I respect the concern and the work. I disagree with the risk calculus. (GitHub
I. Neutrality and First Principles
1. Consensus is Bitcoin’s most powerful intervention. A soft fork makes some blocks that were valid under prior rules invalid to upgraded nodes. That power should be reserved for clear, serious, and broadly understood failures.
2. It is not a repair for an established consensus failure. BIP 110 does not correct inflation, signature validation, double spending, or a known critical bug. It addresses a contested externality and use case, so the burden of proof should be especially high.
3. It elevates a contested judgment into protocol law. The proposal moves a dispute about legitimate use and externalities from relay policy, mining policy, and markets into consensus validity.
4. Bitcoin cannot read intent. The network cannot know whether bytes represent an image, a proof, a contract, metadata, an authentication record, or a future application.
5. Structural proxies create collateral risk. Because intent cannot be known, the proposal restricts technical forms that may serve both disfavored and legitimate purposes.
6. A social message is not sufficient grounds for a consensus change. The specification expressly treats activation as a way to communicate that data storage is unwelcome. Consensus should be changed for compelling technical or monetary reasons, not primarily to express disapproval. (GitHub
7. Disapproval is not invalidity. A transaction can be trivial, speculative, offensive, or wasteful and still follow the rules and pay the fee required for inclusion.
8. It narrows prospective economic freedom on the BIP 110 chain. Pre-activation UTXOs are grandfathered, but users creating UTXOs during the active period would have fewer valid ways to structure and spend them than under existing consensus.
9. Permissionless systems must tolerate unapproved experimentation. Requiring innovators to prove their use worthy before building reverses the meaning of permissionless innovation.
10. It turns protocol conservatism upside down. Conservatism at the base layer should mean reluctance to alter consensus, not eagerness to alter consensus in favor of a conservative use philosophy.
II. The Burden of Proof Has Not Been Met
11. “Spam” is not a consensus primitive. There is no opcode that can distinguish spam from utility. Those labels arise from human judgment.
12. “Monetary” and “nonmonetary” are not cleanly separable. A payment channel, proof of reserves, custody policy, smart contract, or settlement commitment is both financial activity and data.
13. Known use cases are not the full design space. The proposal says it preserves all known monetary use cases. Innovation is defined by what is not yet known.
14. The BIP itself does not quantify the node burden it would remove. It describes costs but does not estimate the relevant bandwidth, storage, validation load, hardware thresholds, or number of node operators likely to be gained or lost.
15. It does not quantify the decentralization benefit. The claim that BIP 110 would improve decentralization is not paired with a measurable model or target.
16. It does not quantify payment relief. It does not estimate how much transaction fees would fall, for how long, or how many payment users would benefit.
17. It combines distinct costs into one diagnosis. UTXO-state growth, initial-sync bandwidth, archival storage, relay burden, and validation time have different causes and may require different remedies.
18. Urgency is asserted rather than operationally defined. The proposal calls the situation urgent and a crisis, but provides no objective threshold at which consensus intervention becomes necessary.
19. A historical relay-policy limit is not proof of an optimal consensus limit. An 83-byte default may be useful policy without becoming a timeless block-validity rule.
20. The 256-byte line is heuristic. The rationale relates it partly to compressed image size and large cryptographic integers, but does not establish 256 bytes as an optimal boundary between safety and innovation. (GitHub
III. The Technical Scope Is Too Broad
21. Seven separate consensus changes are bundled together. Participants cannot support one restriction and reject another. They must accept or reject the package.
22. The strongest technical concern is bundled with unrelated restrictions. Large scriptPubKeys can increase UTXO-state and validation costs. If that creates a measurable hazard, it deserves a narrowly scoped proposal on its own, not automatic support for six additional restrictions. (GitHub
23. The 83-byte OP_RETURN policy becomes consensus. That converts a configurable relay and mining preference into a block-validity rule.
24. The 256-byte limits constrain general primitives. They target data storage by restricting broad classes of pushed payloads and script-argument witness items.
25. Spending undefined witness and Tapleaf versions would be disabled. Those spaces are unused today in part because they are reserved for future upgrades.
26. The Taproot annex would be disabled. BIP 341 reserves the annex for future extensions. Even if users should not employ it before its meaning is defined, closing a deliberate upgrade path should require exceptional justification. (GitHub
27. Taptree depth would be reduced. A 257-byte control-block cap limits revealed script paths to seven levels and can constrain complex script trees.
28. OP_SUCCESSx would be disabled even in unexecuted branches. BIP 342 created these opcodes as clean upgrade hooks for future soft forks. (GitHub
29. Executed OP_IF and OP_NOTIF would be prohibited in Tapscript. The authors regard them as redundant and commonly abused, but also acknowledge experimental uses and possible Miniscript efficiencies.
30. The proposal openly accepts bluntness in exchange for speed. Its rationale says a better-balanced approach would require more development and review, so it chooses simpler restrictions intended for faster deployment. Urgency is not a substitute for precision in consensus code. (GitHub
IV. It Sacrifices Compatibility and Future Optionality
31. It closes several upgrade paths at once. Annexes, future witness versions, future Tapleaf versions, and OP_SUCCESSx are all part of Bitcoin’s reserved design space. (GitHub
32. Reserved does not mean useless. It means earlier designers deliberately preserved option value for needs that had not yet emerged.
33. A one-year closure can still disrupt development timelines. The authors expect future soft forks to require more than a year of coordination, but that is an estimate, not a guarantee.
34. It may complicate BitVM-style designs. The specification acknowledges that the control-block limit could impede advanced off-chain contracting.
35. It may affect Miniscript-generated Tapleaves. The proposal acknowledges that some compiler outputs can contain OP_IF and would need adjustment.
36. It requires changes in affected wallet tooling. The backward-compatibility section states that the Miniscript compiler would need modification while the rules are active.
37. It creates a narrow but admitted fund-access risk. The BIP candidly identifies rare pre-signed Taproot scenarios in which post-activation UTXOs could be frozen or spent unexpectedly.
38. Grandfathering is valuable but not complete insulation. Pre-activation UTXOs are protected, yet workflows that create or spend affected outputs during the deployment can still encounter new constraints.
39. Users are advised to migrate potentially affected funds. A proposal that requires even a narrow class of users to migrate is not a costless filter.
40. “No known use case” is not a safety proof. Private systems, unpublished contracts, experimental wallets, and future protocols are not fully observable. (GitHub
V. Temporary Consensus Rules Still Create Real Complexity
41. Temporary consensus code is still consensus code. It must be specified, implemented, reviewed, tested, deployed, monitored, and later retired.
42. Grandfathering makes validity history-dependent. The same spending construction can be treated differently depending on when the UTXO was created.
43. History-dependent rules increase implementation complexity. Every implementation must identify the relevant UTXO creation height and apply the exemptions identically.
44. Activation creates one critical boundary. Software and economic actors must agree on when the new restrictions begin.
45. Expiration creates another. They must also agree on when the restrictions end and previously restricted behavior becomes valid again.
46. BIP 110 adds a new EXPIRED state. That extends the familiar deployment state machine with new consensus behavior.
47. It removes the conventional FAILED outcome. The proposed deployment cannot simply time out in the ordinary BIP 9 manner.
48. It creates several coordination windows. Voluntary signaling, mandatory signaling, lock-in, activation, and expiration each introduce opportunities for divergence. (GitHub
49. Temporary rules can leave permanent artifacts. Wallet code, operational procedures, contracts, and institutional risk controls may need changes that outlive the deployment.
50. More consensus branches mean more bug surface. Test vectors reduce known risk, but cannot enumerate every private or future interaction.
VI. The Economic and Security Effects Are Uncertain
51. The node externality is real but heterogeneous. Every fully validating node must download and verify blocks, while pruned nodes can discard old raw block data and limit historical storage. The relevant costs should be measured separately. (Bitcoin Core
52. The fee-recipient issue is not unique to data transactions. Miners collect fees while validators bear some costs for every transaction. The magnitude may differ, but the basic structure is universal.
53. Technical costs should be measured directly. For a given amount of data and validation work, resource costs arise from bytes, state, computation, and bandwidth, not from whether observers approve of the transaction’s purpose.
54. BIP 110 cannot eliminate data embedding. The specification acknowledges that users can split data into smaller pieces or disguise it within permitted structures. (GitHub
55. Evasion may make transactions less efficient. Fragmented or obfuscated encodings can consume more structure and complicate analysis without eliminating the underlying demand.
56. The fee effect is ambiguous. Suppressing one use may lower payment fees, reduce aggregate fee revenue, shift demand into other encodings, or produce some combination of the three.
57. Miner revenue matters more as the subsidy declines. Transaction fees are one component of the block reward, while the block subsidy halves every 210,000 blocks. (Bitcoin Developer Docs
58. Lower aggregate fee demand can weaken security at the margin. To the extent BIP 110 reduces total fee demand rather than merely reallocating it, lower miner revenue can reduce the incentive to commit hash power, all else equal.
59. Diverse demand can make the fee market more resilient. Payments, channels, custody systems, financial applications, and other uses need not peak at the same time.
60. The specification does not model the security tradeoff. It argues for cheaper payments and lower node costs without estimating possible effects on miner revenue, hash investment, or long-term fee-market depth.
VII. Better Market and Policy Tools Exist
61. Bitcoin already has a content-neutral capacity constraint. Block weight imposes a common limit on the transaction capacity of each block. (GitHub
62. Fees already ration scarce block space. Users express urgency by bidding, and miners select valid transactions under their own policies.
63. The block limit and fee market do not ask users to declare purpose. They apply technical validity and resource limits rather than a semantic test of whether a transaction is sufficiently monetary.
64. Relay policy remains a less coercive tool. Implementations and node operators can choose which unconfirmed transactions to relay without redefining valid blocks. Bitcoin Core’s data-carrier policy is configurable. (GitHub
65. Mining policy remains voluntary. Miners can exclude transaction classes from their own block templates without forcing every validating node to reject blocks containing them.
66. Policy is imperfect, but imperfection is not failure. Direct submission to miners can bypass relay filters. That limitation deserves analysis, not an automatic leap to consensus prohibition.
67. No transaction has a right to inclusion. A miner may reject a transaction under its own policy, but making a previously valid transaction invalid across a fork is a much more consequential act.
68. Resource pricing can be improved without classifying purpose. If certain structures impose disproportionate costs, Bitcoin can study content-neutral limits or pricing tied to measurable resource use.
69. Pruning and optional-data designs deserve continued research. They may not solve every concern, but they address storage burdens more directly than a rule intended partly to signal that a use is unwelcome.
70. The BIP itself concedes that policy is generally the right place to fight spam. Its inability to guarantee perfect filtering does not by itself prove that consensus must be used. (GitHub
VIII. It Discourages Innovation and Adoption
71. It creates a chilling effect. Developers may avoid Bitcoin if currently valid constructions can be suspended through consensus to suppress a related use.
72. It privileges incumbent use cases. “All known monetary use cases” protects the present, not the future.
73. It destroys option value before value can be discovered. The best future use of an upgrade hook may not yet have a name.
74. Stable foundations matter to long-lived contracts. Wallets, custody systems, payment channels, and financial protocols need confidence that valid transaction structures will remain available.
75. It narrows the script design space. That can make some constructions larger, more expensive, less elegant, or temporarily impossible.
76. It can delay advanced contracting research. The BIP explicitly accepts that BitVM-style work may need to wait or proceed on testnets and sidechains. (GitHub
77. It pushes experimentation away from Bitcoin by consensus. Testnets and sidechains are useful, but builders should not be displaced from the base layer without a compelling security case.
78. Future Layer 2 systems may depend on today’s unused hooks. Base-layer optionality can support scale without requiring frequent base-layer activity.
79. Applications can strengthen money. Better wallets, custody, settlement, credit, securities, and proof systems can increase Bitcoin’s utility, liquidity, and demand.
80. Bitcoin need not choose between money and technology. Its monetary strength can be reinforced by an open network that supports secure wallets, contracts, custody, settlement, and innovation.
IX. The Activation Mechanism Is Too Aggressive
81. The 55 percent threshold is a major departure from BIP 9. BIP 9 specifies a 95 percent miner-readiness threshold; BIP 110 proposes 55 percent.
82. A contentious restriction should demand greater confidence, not less. Temporary duration does not make coordination failure harmless.
83. Miner signaling is not a referendum on all Bitcoin users. Hash power secures and orders transactions, but holders, exchanges, wallets, merchants, custodians, and businesses determine which rules and asset they economically accept.
84. Mandatory signaling changes the meaning of nonparticipation. During the specified window, enforcing nodes would reject blocks that do not signal bit 4.
85. The deployment is designed to lock in no later than a predetermined height on the enforcing chain. That is stronger than merely observing voluntary readiness.
86. The absence of a FAILED state removes a clean off-ramp. A proposal that cannot attract sufficient voluntary support should be able to expire without forced coordination. (GitHub
87. Activation machinery cannot manufacture consensus. It can coordinate software states, but it cannot create social and economic agreement.
88. Divergent enforcement can divide the network. If economically significant participants apply incompatible validity rules, the result can be a chain split or prolonged uncertainty.
89. A temporary split would not be trivial. Liquidity, custody, settlement, accounting, and user confidence could all be affected.
90. Hard consensus is Bitcoin’s immune system. Lowering the bar for a disputed use-case restriction may create a more serious risk than the targeted data-storage problem.
X. The Precedent Is More Dangerous Than the Target
91. The rules expire, but the precedent does not. Future campaigns can cite BIP 110 as evidence that consensus may be used to suppress disfavored valid activity.
92. The same logic can be reused. A faction can label another use nonmonetary, harmful, legally risky, or unsupported and seek its exclusion.
93. “Unsupported use” is an expandable category. Bitcoin has no central product manager who can permanently define its approved scope.
94. Purpose-based boundaries become political boundaries. Once validity turns on judgments about legitimate use, protocol debates become contests over values and power.
95. Today’s target does not limit tomorrow’s target. Privacy tools, novel custody, stablecoin settlement, token systems, corporate applications, or other unpopular uses could face similar arguments. This is not a prediction. It is a governance risk.
96. Every restriction is presented as exceptional. Precedents are created precisely by cases their advocates consider unique.
97. Social cohesion is a scarce asset. Encoding a cultural dispute into consensus can consume trust and coordination capacity needed for more serious threats.
98. Every stakeholder deserves a hearing. Developers, node operators, miners, holders, wallets, exchanges, custodians, companies, and institutions all bear different risks and responsibilities.
99. Capital at risk deserves consideration without conferring control. Large holders, miners, exchanges, custodians, and corporations do not own consensus. Neither do developers or node operators acting alone. Durable agreement requires coordination among all of them.
100. Corporate participation is legitimate when it strengthens Bitcoin. Companies allow people to organize under law with scale, accountability, capital, and continuity. They do not deserve special authority, but they should not be treated as outsiders to a global monetary network.
XI. A Better Path Is Available
101. Participants can oppose data storage without changing consensus. They can decline to use, promote, index, relay, or mine it.
102. Stricter software choices can remain voluntary. Competing implementations and configurable policies are features of an open network, not defects.
103. We can improve measurement before intervention. Publish reproducible data on bandwidth, storage, validation time, UTXO growth, fee displacement, and node economics.
104. We can target measurable resource costs. A narrow rule tied to a demonstrated denial-of-service or validation risk is more defensible than a broad package tied partly to perceived purpose.
105. We can improve data placement. Better commitments, optional storage, pruning, and Layer 2 architectures can reduce burdens while preserving functionality.
106. We can improve fee-market transparency. Better tools and models can show who pays, who bears costs, and which uses actually crowd out payments.
107. We can preserve upgrade hooks while research continues. Unused capacity is not necessarily waste when it protects future soft-fork paths.
108. We can wait for overwhelming alignment. The cost of waiting should be measured against the cost of an unnecessary fork. Absent compelling evidence of emergency and broad agreement, restraint is the safer default.
109. We can disagree without turning allies into enemies. BIP 110 supporters are trying to protect Bitcoin. The respectful response is to address their concerns while rejecting a remedy that creates greater risks.
110. The proposed cure is more dangerous than the condition. BIP 110 would use consensus to narrow valid activity, constrain future options, complicate deployment, and establish a precedent it cannot later erase. That makes it a Bitcoin Iatrogenic Proposal.
Guardians of Neutrality
Bitcoin’s strength is not that everyone agrees on every use. Its strength is that disagreement is contained by neutral rules and hard consensus.
Fees price block space. Nodes choose policy and validate consensus. Miners build blocks. Holders allocate capital. Developers propose code. Companies build infrastructure and applications. Protocol changes should prevail only when validation, security, utility, and capital reach overwhelming alignment.
This is not a defense of every inscription, token, file, or application. It is a defense of the neutral rules that allow Bitcoin to remain open while markets reward what is useful and abandon what is not.
Bitcoin should remain conservative at the base layer. For me, that means rejecting BIP 110.
Bitcoin does not need guardians of purity.
It needs guardians of neutrality.
Primary Sources
This analysis is based principally on BIP 110 version 1.0.0; BIP 3’s process and status definitions; BIP 9’s activation design; BIPs 141, 341, and 342; Bitcoin Core’s data-carrier policy documentation; Bitcoin Core’s pruning documentation; and the Bitcoin developer block-reward reference. (GitHub
