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

# bitcoin# blockchain# security# opensource

InvisibleHill

Originally published by InvisibleHill Research. This cross-post preserves the original research...

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 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.