BIP 110 and the Cost of Policing Bitcoin's Block Space
Originally published byInvisibleHill Research. This cross-post preserves the original research cut-off and source list. Research cut-off: July 30, 2026. Miner signaling is a live metric and may have changed. . .
Originally published byInvisibleHill Research. This cross-post preserves the original research cut-off and source list. Research cut-off: July 30, 2026. Miner signaling is a live metric and may have changed after publication. BIP 110 begins with a problem that many Bitcoin users can recognize. A minercan collect a one-time fee for including an image, token payload, or otherarbitrary data, while thousands of node operators absorb the cost ofdownloading, validating, and sometimes storing it. The proposal's authors seethat mismatch as a subsidy for data storage and a threat to Bitcoin's use asmoney. Their answer is a temporary soft fork. For about one year, BIP 110 would makeseveral currently valid transaction structures invalid under consensus rules. It would cap OP_RETURN outputs at 83 bytes, limit many data pushes and witnessitems to 256 bytes, restrict large output scripts and Taproot control blocks,and disable several Taproot upgrade paths and script features that can carrydata. Adam Back agrees with the premise more than his opposition sometimes suggests. He has said that Bitcoin is about money and that spam has no place in itstimechain. He also designed Hashcash to make spam costly. His objection is tothe remedy. In Back's view, an annoyance that fits inside Bitcoin's existingblock limit does not justify a contentious consensus change, especially onethat can be bypassed, can interfere with legitimate scripts, and has not earnedtechnical or economic agreement. That distinction is the center of the debate. BIP 110 asks whether Bitcoinshould discourage an unwanted use through local policy and fees, or declaresome forms of that use invalid for everyone. Back's case is stronger on thisquestion. The proposal identifies a real externality, but it offers anasymmetric bargain: incomplete filtering in exchange for a new consensusprecedent, a more complicated upgrade path, and a material risk of a minoritychain. A policy dispute became a consensus proposalThe immediate background is Bitcoin Core 30. 0. Released in October 2025, itraised the default-datacarriersizesetting to 100,000 bytes, effectivelyremoving the previous OP_RETURN relay limit because the standard transactionsize limit is reached first. It also allowed multiple data-carrier outputswithin one transaction. Operators can still set the limit back to 83 bytes. This was a change in node policy, not Bitcoin consensus. Policy determineswhich valid unconfirmed transactions a node will relay and which validtransactions a miner may place in its candidate block. Different nodes andminers may choose different policies. Consensus determines whether a confirmedblock is Bitcoin at all. A transaction filtered by one node can still reach aminer through another route, and a block containing it remains valid to thenetwork. BIP 110 crosses that boundary. Formally titled the Reduced Data TemporarySoftfork, it would add seven consensus restrictions for one year:New output scripts could not exceed 34 bytes, except for an OP_RETURN output of up to 83 bytes. Many pushed data fields and script-argument witness items would be limited to 256 bytes. Spending undefined witness or Tapleaf versions would be invalid. Taproot annexes would be invalid. Taproot control blocks would be limited to 257 bytes. Tapscripts containing anOP_SUCCESSopcode would be invalid. Tapscripts executingOP_IForOP_NOTIFwould be invalid. Outputs created before activation are grandfathered. After the temporaryperiod expires, the extra rules disappear. The proposal reached "Complete"status in the BIP repository on June 25, 2026, which means its specification iscomplete. It does not mean Bitcoin has accepted or activated it. The deployment is unusually assertive. Early lock-in requires 1,109 of 2,016blocks, or 55 percent, to signal with version bit 4. If that threshold is notreached voluntarily, BIP 110 nodes enter a mandatory signaling period at block961,632. During that period they reject non-signaling blocks. Lock-in followsno later than block 963,648, with the new transaction rules scheduled to becomeactive at block 965,664. At 15:35 UTC on July 30, the public BIP 110 monitor showed 14 signaling blocksout of 655 in difficulty period 476, a rate of 2. 14 percent against the55 percent target. That snapshot does not determine the final outcome, but itshows how far the proposal remained from coordinated miner activation shortlybefore mandatory signaling. The strongest case for BIP 110Reducing the proposal to a fight over JPEGs misses its best argument. Bitcoin block space has a hard supply. Data transactions compete with paymentsfor that space and can raise fees when demand is high. The miner receives thefee, while every validating node must process the block. Archival nodes retainthe data, and pruned nodes must still download and validate it during initialsync. Large spendable output scripts are more costly because they can remainin the UTXO set, which nodes need to query quickly. The cost is bounded by Bitcoin's block-weight limit, and pruning reducesstorage requirements. It is not imaginary. One party can buy permanentpublication while distributing part of the bill to infrastructure it does notpay. BIP 110 supporters are also right that a fee market does not compensateevery node operator. It compensates miners for block production. The proposal has several thoughtful safeguards. It is temporary rather thanpermanent. It preserves pre-activation UTXOs. It provides test vectors and areference implementation. Its limits are simple enough to audit. It openlyadmits that BitVM, Miniscript constructions, future upgrade hooks, and someexperimental Taproot uses may be constrained. That is better than presenting afilter as costless. BIP 110 also does not claim that steganography can be eliminated. A determineduser can split data into smaller pushes or disguise it inside structures withanother protocol meaning. The authors' narrower goal is to make contiguous,obvious publication more cumbersome and to state that arbitrary data storageis unsupported. That may work as a social and economic deterrent. Raising the engineering costof an activity can reduce casual use even when it cannot stop a determinedactor. A temporary rule could also buy time for a cleaner design that separatesoptional data from the material every node must validate. The difficulty is that this modest technical effect is paired with a much lessmodest activation mechanism. Adam Back's boundary: dislike is not a consensus ruleBack's position is useful because it does not depend on liking inscriptions,Runes, or other data-heavy applications. He dislikes spam. In September 2025,he wrote that Bitcoin is owned by humanity, that protocol developers arestewards, and that material changes require user consensus. By February 2026,he was arguing that BIP 110 would damage Bitcoin's credibility as a store ofvalue and secure monetary network. In the same exchange he called spam "justan annoyance. "His longer July argument starts from permissionless money. The decentralizationneeded to create bearer money also prevents one faction from imposing itspreferences on everyone else. A user can change personal software, but notanother user's software. Back therefore describes BIP 110 as an attempt topolice other people through consensus, even if its supporters believe they aredefending Bitcoin. He also emphasizes the engineering process. Bitcoin's change resistancedepends on much more than a high miner threshold. It includes review by developers, protocolresearchers, wallet authors, miners, exchanges, custodians, and users who canrefuse a change. Back compares this to an IETF-style technical consensus inwhich unresolved objections block progress. In July he summarized the outcomeplainly: "Bitcoin respectfully says no to what you want. "That sentence is rhetoric, not a formal vote. Back does not own Bitcoin, andneither do Bitcoin Core developers. His argument should stand on its mechanics,not his biography. Here the mechanics support him. BIP 110 has weak minersignaling, no demonstrated coalition of major exchanges or custodians, andunresolved technical objections. The proposal's mandatory path does not createconsensus. It schedules a test of whether consensus exists. Back's position also explains why opposing BIP 110 is compatible with runningstricter relay policy. A node operator can filter locally. A mining pool candecline transactions. Bitcoin Knots can offer different defaults from BitcoinCore. Those choices compete without declaring the other side's blocks invalid. This diversity is less satisfying to anyone seeking a universal ban, but itpreserves a valuable boundary between individual judgment and shared validity. The technical exchange is asymmetricBIP 110's filtering is intentionally incomplete. In October 2025, Peter Todddemonstrated a transaction that embedded the text of the proposal whileremaining compliant with its rules. Later examples showed that larger imagescould also be encoded through permitted structures. These demonstrations donot prove that the proposal has zero effect. They do prove that arbitrary datawill survive activation. The users most motivated to evade the filter can update their encodingsoftware. Ordinary wallet and contract users may have a harder problem. BIP110 disables tools that were reserved for future upgrades and restrictsfeatures that are not inherently data storage. It forbids Taproot annexes,OP_SUCCESSopcodes, undefined witness versions, deep control blocks, andexecuted conditionals in Tapscript. Some are unused today. Others are buildingmaterials for future protocols. The proposal itself acknowledges the tradeoffs. A 257-byte control-block limitcan complicate BitVM and other large script trees. Current Miniscript compilerscan produce Tapleaves containingOP_IF. No new soft fork can use the disabledupgrade hooks during the one-year window. Wallets and libraries must understandone rule set during the intervention and another after it expires. Grandfathering protects outputs confirmed before activation, but it cannotcover every pre-existing commitment. A user may hold a pre-signed chain oftransactions in which a descendant confirms after activation. To BIP 110nodes, that descendant creates a new UTXO even though the owner committed to itearlier. If its only spending path violates the temporary rules, the funds canbecome unspendable until expiry. In the Bitcoin development mailing list,Gregory Maxwell pointed to inheritance plans and other pre-signed arrangementsas plausible examples. The BIP calls such cases unlikely and imposes several conditions before fundscan be frozen or lost. That may be accurate. It is still the wrong comparisonto ask whether the number is probably small. The comparison is between theexpected benefit of a bypassable filter and the expected cost of changing thevalidity of unknown, privately constructed spending arrangements. Back's critique is compelling because the asymmetry points in the wrongdirection. Sophisticated data publishers route around the restriction. Legitimate users cannot route around a consensus rule after their spendingconditions have been fixed. The activation design carries the largest immediate riskA soft fork is backward compatible only when the economic majority follows themore restrictive chain. Old nodes will accept blocks produced under the newrules. Upgraded nodes will reject blocks that violate them. If most minersenforce the restriction, both groups stay on one chain. If only a small minority enforces it, the result is different. At the mandatorysignaling height, BIP 110 nodes reject blocks that the rest of the networkaccepts. Unless enough hash power follows them, those nodes move onto alow-hashrate minority chain. Transactions may be valid on both chains, depositsbecome difficult for exchanges to credit safely, and users face replay anddouble-spend risk. The one-year expiration does not make that coordinationproblem temporary in any reassuring sense. Supporters compare the plan with the 2017 user-activated soft fork campaign forSegWit. The analogy is incomplete. SegWit had years of engineering review,broad wallet and infrastructure integration, and overwhelming economic supportbefore the threatened UASF date. Miners ultimately activated it through theexisting signaling process, so the UASF did not have to split the network. BIP 110's 55 percent threshold is much lower than the 95 percent used bytraditional BIP 9 deployments, and the mandatory period is meant to force theissue if voluntary signaling fails. A threshold can coordinate actors whoalready want the same change. It cannot manufacture demand from miners,exchanges, wallets, and holders who have not agreed to bear the fork risk. This is where node counts can mislead. Reachable nodes are not ballots, andcreating many nodes is cheap. What matters during a fork is the economic weightthat miners need to serve: exchanges that value coinbase rewards, merchantsthat accept payments, custodians that control deposits and withdrawals, andholders willing to price the two assets differently. BIP 110 has generated avisible movement. It has not yet demonstrated that coalition. What BIP 110 changes even if it failsBIP 110 is unlikely to make arbitrary data disappear. Its more durable effectwill be a clearer map of Bitcoin's governance limits. First, policy diversity will matter more. Bitcoin Core 30's OP_RETURN defaulthelped turn an implementation choice into an identity dispute. Bitcoin Knots,mining-pool templates, and operator settings provide a way to express stricterpreferences without a consensus fork. Future client teams may treat policydefaults as politically consequential even when they do not alter consensus. Second, a failed activation would raise the bar for the next UASF. The lessonwould not be that users are powerless. It would be that user power becomeseffective only when it is connected to wallets, businesses, liquidity, andhash rate. A social-media node count cannot substitute for economiccoordination. Third, the technical questions will remain. Node operators still bear coststhat block-space buyers do not fully pay. Pruning, faster initial sync,assumeUTXO, more efficient validation, optional data transport, and betterpolicy tools can reduce that burden without classifying transactions bypurpose at consensus. None is a perfect answer. They attack the cost directlyinstead of treating cultural disapproval as a script rule. The fee market will remain contested as the block subsidy declines. Dataapplications can crowd out low-fee payments during bursts of demand. They canalso provide transaction fees to miners when monetary settlement demand isweak. BIP 110 chooses monetary purity over that source of security revenuewithout showing that payments alone will reliably replace it. The ecosystemneeds evidence about sustained fee demand, node costs, and user behavior morethan it needs a permanent label for spam. Finally, the precedent matters. If Bitcoin changes consensus rules to suppressone legal but disliked use, future campaigns can argue that other controversialtransactions deserve the same treatment. Governments and private pressuregroups would learn that transaction eligibility is negotiable. Back'sneutrality argument is strongest here. Censorship resistance is crediblepartly because participants can say that they lack the practical consensus tomake selective exceptions. Why policy is the better layerBIP 110 deserves a more serious answer than mockery. It documents a genuinecost externality, gives node operators a political voice, and forces theecosystem to confront what scarce block space is for. Its temporary design andUTXO grandfathering show that the authors tried to contain collateral damage. The proposal still fails its own risk test. It cannot eliminate arbitrary data. It interferes with legitimate and future script uses. It creates edge cases forpre-signed transactions. Its changing rule set burdens wallet and protocoldevelopers. Most of all, its mandatory activation path can split the networkwithout evidence that the economic majority wants the change. Adam Back's opposition is persuasive because it keeps the layers separate. Hecan dislike spam, support money as Bitcoin's primary purpose, and still rejecta consensus filter. Local policy lets an operator refuse a transaction withoutrequiring every other operator to share that judgment. Consensus decides whichblocks belong to Bitcoin's ledger. Bitcoin may eventually adopt narrower limits or a better architecture foroptional data. Such a proposal would need to reduce measurable node costs,preserve upgrade hooks, protect existing spending arrangements, resist trivialbypass, and earn broad technical and economic support before activation. BIP 110 does not meet that standard. Its longer legacy may be useful anyway. Bitcoin's participants plainly do notagree on acceptable behavior. The network protects neutrality by making anyfaction's preferred restrictions unusually difficult to impose on everyoneelse, including when that faction believes it is protecting Bitcoin. SourcesThis analysis distinguishes relay and mining policy from consensus validity. It treats the BIP specification, code-linked test vectors, Bitcoin developmentmailing list, Bitcoin Core release notes, and Adam Back's own public statementsas primary sources. Signaling data is a point-in-time snapshot, not a forecast. Technical claims are current through July 30, 2026. BIP 110, Reduced Data Temporary SoftforkBitcoin development mailing-list discussion of BIP 110Bitcoin Core 30. 0 release notesBIP 110 live miner-signaling monitorAdam Back on BIP 110, credibility, and consensusAdam Back on censorship resistance and breakageAdam Back on decentralization and technical consensus