BIP 110 and the Cost of Policing Bitcoin's Block Space

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 miner can collect a one-time fee for including an image, token payload, or other arbitrary data, while thousands of node operators absorb the cost of downloading, validating, and sometimes storing it. The proposal's authors see that mismatch as a subsidy for data storage and a threat to Bitcoin's use as money.

Their answer is a temporary soft fork. For about one year, BIP 110 would make several currently valid transaction structures invalid under consensus rules. It would cap OP_RETURN outputs at 83 bytes, limit many data pushes and witness items to 256 bytes, restrict large output scripts and Taproot control blocks, and disable several Taproot upgrade paths and script features that can carry data.

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 its timechain. He also designed Hashcash to make spam costly. His objection is to the remedy. In Back's view, an annoyance that fits inside Bitcoin's existing block limit does not justify a contentious consensus change, especially one that can be bypassed, can interfere with legitimate scripts, and has not earned technical or economic agreement.

That distinction is the center of the debate. BIP 110 asks whether Bitcoin should discourage an unwanted use through local policy and fees, or declare some forms of that use invalid for everyone. Back's case is stronger on this question. The proposal identifies a real externality, but it offers an asymmetric bargain: incomplete filtering in exchange for a new consensus precedent, a more complicated upgrade path, and a material risk of a minority chain.

A policy dispute became a consensus proposal

The immediate background is Bitcoin Core 30.0. Released in October 2025, it raised the default -datacarriersize setting to 100,000 bytes, effectively removing the previous OP_RETURN relay limit because the standard transaction size limit is reached first. It also allowed multiple data-carrier outputs within one transaction. Operators can still set the limit back to 83 bytes.

This was a change in node policy, not Bitcoin consensus. Policy determines which valid unconfirmed transactions a node will relay and which valid transactions a miner may place in its candidate block. Different nodes and miners may choose different policies. Consensus determines whether a confirmed block is Bitcoin at all. A transaction filtered by one node can still reach a miner through another route, and a block containing it remains valid to the network.

BIP 110 crosses that boundary. Formally titled the Reduced Data Temporary Softfork, it would add seven consensus restrictions for one year:

1. New output scripts could not exceed 34 bytes, except for an OP_RETURN output of up to 83 bytes.
2. Many pushed data fields and script-argument witness items would be limited to 256 bytes.
3. Spending undefined witness or Tapleaf versions would be invalid.
4. Taproot annexes would be invalid.
5. Taproot control blocks would be limited to 257 bytes.
6. Tapscripts containing an OP_SUCCESS opcode would be invalid.
7. Tapscripts executing OP_IF or OP_NOTIF would be invalid.

Outputs created before activation are grandfathered. After the temporary period expires, the extra rules disappear. The proposal reached "Complete" status in the BIP repository on June 25, 2026, which means its specification is complete. It does not mean Bitcoin has accepted or activated it.

The deployment is unusually assertive. Early lock-in requires 1,109 of 2,016 blocks, or 55 percent, to signal with version bit 4. If that threshold is not reached voluntarily, BIP 110 nodes enter a mandatory signaling period at block 961,632. During that period they reject non-signaling blocks. Lock-in follows no later than block 963,648, with the new transaction rules scheduled to become active at block 965,664.

At 15:35 UTC on July 30, the public BIP 110 monitor showed 14 signaling blocks out of 655 in difficulty period 476, a rate of 2.14 percent against the 55 percent target. That snapshot does not determine the final outcome, but it shows how far the proposal remained from coordinated miner activation shortly before mandatory signaling.

The strongest case for BIP 110

Reducing the proposal to a fight over JPEGs misses its best argument.

Bitcoin block space has a hard supply. Data transactions compete with payments for that space and can raise fees when demand is high. The miner receives the fee, while every validating node must process the block. Archival nodes retain the data, and pruned nodes must still download and validate it during initial sync. Large spendable output scripts are more costly because they can remain in the UTXO set, which nodes need to query quickly.

The cost is bounded by Bitcoin's block-weight limit, and pruning reduces storage requirements. It is not imaginary. One party can buy permanent publication while distributing part of the bill to infrastructure it does not pay. BIP 110 supporters are also right that a fee market does not compensate every node operator. It compensates miners for block production.

The proposal has several thoughtful safeguards. It is temporary rather than permanent. It preserves pre-activation UTXOs. It provides test vectors and a reference implementation. Its limits are simple enough to audit. It openly admits that BitVM, Miniscript constructions, future upgrade hooks, and some experimental Taproot uses may be constrained. That is better than presenting a filter as costless.

BIP 110 also does not claim that steganography can be eliminated. A determined user can split data into smaller pushes or disguise it inside structures with another protocol meaning. The authors' narrower goal is to make contiguous, obvious publication more cumbersome and to state that arbitrary data storage is unsupported.

That may work as a social and economic deterrent. Raising the engineering cost of an activity can reduce casual use even when it cannot stop a determined actor. A temporary rule could also buy time for a cleaner design that separates optional data from the material every node must validate.

The difficulty is that this modest technical effect is paired with a much less modest activation mechanism.

Adam Back's boundary: dislike is not a consensus rule

Back'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 are stewards, and that material changes require user consensus. By February 2026, he was arguing that BIP 110 would damage Bitcoin's credibility as a store of value and secure monetary network. In the same exchange he called spam "just an annoyance."

His longer July argument starts from permissionless money. The decentralization needed to create bearer money also prevents one faction from imposing its preferences on everyone else. A user can change personal software, but not another user's software. Back therefore describes BIP 110 as an attempt to police other people through consensus, even if its supporters believe they are defending Bitcoin.

He also emphasizes the engineering process. Bitcoin's change resistance depends on much more than a high miner threshold. It includes review by developers, protocol researchers, wallet authors, miners, exchanges, custodians, and users who can refuse a change. Back compares this to an IETF-style technical consensus in which unresolved objections block progress. In July he summarized the outcome plainly: "Bitcoin respectfully says no to what you want."

That sentence is rhetoric, not a formal vote. Back does not own Bitcoin, and neither do Bitcoin Core developers. His argument should stand on its mechanics, not his biography. Here the mechanics support him. BIP 110 has weak miner signaling, no demonstrated coalition of major exchanges or custodians, and unresolved technical objections. The proposal's mandatory path does not create consensus. It schedules a test of whether consensus exists.

Back's position also explains why opposing BIP 110 is compatible with running stricter relay policy. A node operator can filter locally. A mining pool can decline transactions. Bitcoin Knots can offer different defaults from Bitcoin Core. Those choices compete without declaring the other side's blocks invalid. This diversity is less satisfying to anyone seeking a universal ban, but it preserves a valuable boundary between individual judgment and shared validity.

The technical exchange is asymmetric

BIP 110's filtering is intentionally incomplete. In October 2025, Peter Todd demonstrated a transaction that embedded the text of the proposal while remaining compliant with its rules. Later examples showed that larger images could also be encoded through permitted structures. These demonstrations do not prove that the proposal has zero effect. They do prove that arbitrary data will survive activation.

The users most motivated to evade the filter can update their encoding software. Ordinary wallet and contract users may have a harder problem. BIP 110 disables tools that were reserved for future upgrades and restricts features that are not inherently data storage. It forbids Taproot annexes, OP_SUCCESS opcodes, undefined witness versions, deep control blocks, and executed conditionals in Tapscript. Some are unused today. Others are building materials for future protocols.

The proposal itself acknowledges the tradeoffs. A 257-byte control-block limit can complicate BitVM and other large script trees. Current Miniscript compilers can produce Tapleaves containing OP_IF. No new soft fork can use the disabled upgrade hooks during the one-year window. Wallets and libraries must understand one rule set during the intervention and another after it expires.

Grandfathering protects outputs confirmed before activation, but it cannot cover every pre-existing commitment. A user may hold a pre-signed chain of transactions in which a descendant confirms after activation. To BIP 110 nodes, that descendant creates a new UTXO even though the owner committed to it earlier. If its only spending path violates the temporary rules, the funds can become unspendable until expiry. In the Bitcoin development mailing list, Gregory Maxwell pointed to inheritance plans and other pre-signed arrangements as plausible examples.

The BIP calls such cases unlikely and imposes several conditions before funds can be frozen or lost. That may be accurate. It is still the wrong comparison to ask whether the number is probably small. The comparison is between the expected benefit of a bypassable filter and the expected cost of changing the validity of unknown, privately constructed spending arrangements.

Back's critique is compelling because the asymmetry points in the wrong direction. Sophisticated data publishers route around the restriction. Legitimate users cannot route around a consensus rule after their spending conditions have been fixed.

The activation design carries the largest immediate risk

A soft fork is backward compatible only when the economic majority follows the more restrictive chain. Old nodes will accept blocks produced under the new rules. Upgraded nodes will reject blocks that violate them. If most miners enforce the restriction, both groups stay on one chain.

If only a small minority enforces it, the result is different. At the mandatory signaling height, BIP 110 nodes reject blocks that the rest of the network accepts. Unless enough hash power follows them, those nodes move onto a low-hashrate minority chain. Transactions may be valid on both chains, deposits become difficult for exchanges to credit safely, and users face replay and double-spend risk. The one-year expiration does not make that coordination problem temporary in any reassuring sense.

Supporters compare the plan with the 2017 user-activated soft fork campaign for SegWit. The analogy is incomplete. SegWit had years of engineering review, broad wallet and infrastructure integration, and overwhelming economic support before the threatened UASF date. Miners ultimately activated it through the existing 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 by traditional BIP 9 deployments, and the mandatory period is meant to force the issue if voluntary signaling fails. A threshold can coordinate actors who already 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, and creating many nodes is cheap. What matters during a fork is the economic weight that miners need to serve: exchanges that value coinbase rewards, merchants that accept payments, custodians that control deposits and withdrawals, and holders willing to price the two assets differently. BIP 110 has generated a visible movement. It has not yet demonstrated that coalition.

What BIP 110 changes even if it fails

BIP 110 is unlikely to make arbitrary data disappear. Its more durable effect will be a clearer map of Bitcoin's governance limits.

First, policy diversity will matter more. Bitcoin Core 30's OP_RETURN default helped turn an implementation choice into an identity dispute. Bitcoin Knots, mining-pool templates, and operator settings provide a way to express stricter preferences without a consensus fork. Future client teams may treat policy defaults as politically consequential even when they do not alter consensus.

Second, a failed activation would raise the bar for the next UASF. The lesson would not be that users are powerless. It would be that user power becomes effective only when it is connected to wallets, businesses, liquidity, and hash rate. A social-media node count cannot substitute for economic coordination.

Third, the technical questions will remain. Node operators still bear costs that block-space buyers do not fully pay. Pruning, faster initial sync, assumeUTXO, more efficient validation, optional data transport, and better policy tools can reduce that burden without classifying transactions by purpose at consensus. None is a perfect answer. They attack the cost directly instead of treating cultural disapproval as a script rule.

The fee market will remain contested as the block subsidy declines. Data applications can crowd out low-fee payments during bursts of demand. They can also provide transaction fees to miners when monetary settlement demand is weak. BIP 110 chooses monetary purity over that source of security revenue without showing that payments alone will reliably replace it. The ecosystem needs evidence about sustained fee demand, node costs, and user behavior more than it needs a permanent label for spam.

Finally, the precedent matters. If Bitcoin changes consensus rules to suppress one legal but disliked use, future campaigns can argue that other controversial transactions deserve the same treatment. Governments and private pressure groups would learn that transaction eligibility is negotiable. Back's neutrality argument is strongest here. Censorship resistance is credible partly because participants can say that they lack the practical consensus to make selective exceptions.

Why policy is the better layer

BIP 110 deserves a more serious answer than mockery. It documents a genuine cost externality, gives node operators a political voice, and forces the ecosystem to confront what scarce block space is for. Its temporary design and UTXO 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 for pre-signed transactions. Its changing rule set burdens wallet and protocol developers. Most of all, its mandatory activation path can split the network without evidence that the economic majority wants the change.

Adam Back's opposition is persuasive because it keeps the layers separate. He can dislike spam, support money as Bitcoin's primary purpose, and still reject a consensus filter. Local policy lets an operator refuse a transaction without requiring every other operator to share that judgment. Consensus decides which blocks belong to Bitcoin's ledger.

Bitcoin may eventually adopt narrower limits or a better architecture for optional data. Such a proposal would need to reduce measurable node costs, preserve upgrade hooks, protect existing spending arrangements, resist trivial bypass, 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 not agree on acceptable behavior. The network protects neutrality by making any faction's preferred restrictions unusually difficult to impose on everyone else, including when that faction believes it is protecting Bitcoin.

Sources

This analysis distinguishes relay and mining policy from consensus validity. It treats the BIP specification, code-linked test vectors, Bitcoin development mailing list, Bitcoin Core release notes, and Adam Back's own public statements as 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 Softfork
• Bitcoin development mailing-list discussion of BIP 110
• Bitcoin Core 30.0 release notes
• BIP 110 live miner-signaling monitor
• Adam Back on BIP 110, credibility, and consensus
• Adam Back on censorship resistance and breakage
• Adam Back on decentralization and technical consensus