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

Originally published by InvisibleHill 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 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: - 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 an OP_SUCCESS opcode would be invalid. - Tapscripts executing OP_IF orOP_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 upgrad