Order of Operations

Let me steelman the other side first, because I’m tired of watching people knock down a fictional version. The real case for BIP-110 is not “I don’t want to see monkey JPEGs.” It’s that arbitrary data in a block is a socialized, permanent cost: every full node on Earth validates it, and depending on where it lands, stores it forever. You personally filtering your own mempool does exactly nothing about that — that’s relay policy, not consensus. It’s a consensus-set problem, not a personal-preference problem. So if you’re going to argue against 110, you have to beat that. Let’s actually beat it.

What BIP-110 actually is

BIP-110, the “Reduced Data Temporary Softfork” from Dathon Ohm, is a one-year set of seven consensus rules aimed at data. The load-bearing ones: any new output over 34 bytes is invalid unless it’s an OP_RETURN (capped at 83 bytes), data pushes over 256 bytes are invalid, and — pointed straight at inscriptions — any tapscript that executes OP_IF/OP_NOTIF is invalid, because the inscription envelope is literally OP_FALSE OP_IF … OP_ENDIF. (I took that specific rule apart separately.)

And here’s the part people gloss, and it’s worth getting the label right: BIP-110 is a modified BIP-9 deployment — bit 4, a 55% threshold (1,109 of 2,016), no timeout, and a hard activation deadline instead — run with a mandatory-signaling window where non-signaling blocks are rejected, and a UASF-flavored Knots build circulating alongside it. Lock-in at height 963,648, activation at 965,664 (around September 1, 2026), then it self-expires about a year later — the “transitory soft fork” pattern lifted straight from the Consensus Cleanup discussion.

Why 110 loses, four ways

You can’t tell data from money. A public key is a number. A signature is a number. There’s no consensus rule that separates “a real pubkey” from “32 bytes of a picture,” because there’s no difference. So any restriction is either bypassed or it starts rejecting legitimate spends. Peter Todd settled this by embedding the entire text of BIP-110 into a fully BIP-110-compliant transaction.

It attacks the least-harmful doors — and can make things worse. There are three doors data walks through, worst to best. Door 1, fake spendable outputs — junk pubkeys, bare multisig — every node carries them in the UTXO set forever, because nothing proves they’re unspendable. Permanent pollution. Door 2, the taproot witness (inscriptions), cheap because the SegWit discount prices witness bytes at 1 weight unit versus 4 for base data; persistent, and here’s the part everyone skips — only theoretically prunable. No Bitcoin client has ever implemented selective witness pruning. The discount exists; the pruning capability it was priced on does not. Door 3, OP_RETURN — provably unspendable, so it never enters the UTXO set at all. Door 3 is the least harmful place data can land. Which is exactly why Bitcoin Core spent 2025 raising the OP_RETURN limit in v30 — from 83 bytes to 100,000, on October 10 — instead of lowering it: choke Door 3 and the data just shoves toward Doors 1 and 2. BIP-110 caps outputs at 34 bytes to blunt Door 1, credit where due — but 34 bytes is still a UTXO you can mint by the thousand, and Todd already showed you can stay fully compliant and write whatever you want. The fork buys a harder-to-read chain, not a data-free one.

It can strand valid coins. Greg Maxwell has noted that there are likely chains of already-presigned (and potentially timelocked) transactions that would violate 110’s new rules — coins valid today, unspendable tomorrow. A rule aimed at data reaching back to invalidate ordinary spends is a genuine cost, and the broader precedent it sets — consensus rules used to decide which coins are spendable — deserves its own careful treatment. Here it’s enough to put it on the ledger against a fork whose upside is already this thin.

The activation is the real red flag. A 55% soft fork that rejects non-signaling blocks during a mandatory window is a chain-split machine — which is why both Jameson Lopp and Adam Back are waving their arms. SegWit needed 95%. Taproot needed 90%. The proposal’s own BitcoinTalk thread rejected it near-unanimously. You don’t force a contested content rule through on a coerced bare majority.

“Why would anyone in their right mind voluntarily take a pay cut?” … a “never-ending game of cat and mouse” … “not a neutral, low-drama deployment posture” … “dogmatic bullying” … “a reckless gamble.” — Jameson Lopp, A Layman’s Guide to BIP-110

What BIP-54 buys — and what it costs

Here’s where I owe 54 the same scrutiny I gave 110, because if I’m telling you to ship it first, “trust me, it’s just cleanup” is not good enough. The Consensus Cleanup — Matt Corallo in 2019, revived by Antoine Poinsot, merged in 2025 — is four fixes, and unlike 110 each closes a measurable attack.

Timewarp — the flood 110 ignores. This is the one every “we have to stop the spam” voice should sit with. The timewarp bug lets a majority-hashrate attacker drive difficulty to its floor within ~38 days, and at the floor the Median-Time-Past rule still permits roughly six blocks per second. If those blocks run full, that is on the order of ~24 MB per second of chaindata in the worst case — enough to overwhelm node CPU and bandwidth and wreck the issuance schedule, at a scale no normal inscription wave approaches. If your real worry is miners abusing the system and data you can’t run a node against, this is a far larger version of exactly that — and BIP-54 closes it, while BIP-110 doesn’t touch it. The fix: at each retarget boundary a block’s timestamp can’t sit more than two hours below the previous block’s.

Slow blocks — a 40× DoS. A cap of 2,500 signature operations per transaction cuts worst-case block validation time by a factor of 40. The threshold was chosen as the tightest value that breaks no non-pathological standard transaction.

64-byte transactions — forged SPV proofs. A 64-byte transaction can be read as both a Merkle leaf and an inner node, letting an attacker forge an inclusion proof against a light client. These have been non-standard since 2019, unused since 2016, and can only be anyone-can-spend or burn — no legitimate use exists.

Duplicate coinbase — replay protection, cheaply. Rather than revive full BIP-30 checks, it pins the coinbase nLockTime to block height minus one, so a coinbase can’t be replayed.

Now the honest part, because 54 is neither free nor unopposed — there’s an organized case against it. Like any tightening soft fork it does make some currently-valid transactions invalid. And the coinbase-nLockTime rule burns a field miners use as extra nonce space and is permanent — you can’t undo it without a hard fork — so some argue: don’t spend a scarce coinbase field now on a non-urgent problem a later fork could fix. Jeremy Rubin pressed on the 64-byte rule specifically — that banning a whole size-class of transactions adds a validity “seam” that could complicate future scripting, and that a new (sparse) Merkle tree might be the cleaner fix — though he was careful to frame it as raising an issue for precision, not a firm objection, and conceded no present-day use for 64-byte transactions exists. So “uncontested” is too strong; call it relatively uncontroversial — the fights are over which rule and what timing, not over whether the bugs are real.

It isn’t “neutral vs. political”

Here’s the part I’d have caught anyone else being glib about. Both forks invalidate currently-valid transactions — that’s just what a tightening soft fork does. So the honest case for 54-first can’t be “it changes nothing.” It rests on three differences, and every one cuts against 110:

Legitimacy of the target. 54 invalidates attack-only, pathological, or unused-since-2016 constructs. 110 invalidates things people are actively using and paying fees for.

Confiscation. 54’s designers treated it as a hard constraint: the 2,500-sigop threshold was chosen as the tightest value that breaks no non-pathological standard transaction, an earlier script-disabling approach was dropped specifically over confiscation concerns, and the 64-byte outputs it invalidates were anyone-can-spend or burn to begin with. 110, by Maxwell’s reading, can render already-presigned transactions permanently unspendable. One engineers around confiscation; the other accepts it as collateral.

Efficacy. A 64-byte transaction is simply invalid after 54 — the fix works. A data payload is trivially re-encoded to survive 110 — the fix doesn’t. A cleanup that closes real attacks with no legitimate casualties is a different kind of object than a content rule that’s bypassable, contested, and potentially confiscatory.

The strongest version of the other side

Now let me argue against myself, because if I only ever punch down I’m doing the exact thing I accused the 110 crowd of. Here is the best case for treating this as urgent — the one that actually gives me pause.

The data externality is real, and it compounds. Every byte written to a block is validated and stored by every full node, and the cost of running one of those is precisely what keeps Bitcoin decentralized and censorship-resistant. Price node operation high enough and fewer people self-validate; erode self-validation and you’ve quietly weakened the security model that makes the whole thing work. That’s not aesthetics — that’s a load-bearing wall.

And the fee market does not actually price this. A data buyer pays today’s miner for today’s blockspace. He does not pay the person who spins up a node in 2035 and has to download and verify his JPEG forever. That’s a textbook unpriced externality — the cost is socialized across every future validator — and markets do not self-correct externalities without a rule. “Let the fee market handle it” is not the slam dunk the permissive camp thinks it is.

Worse, waiting isn’t free. Consensus is ossifying; every year the network gets harder to change. And every month the permissive status quo runs, more of the economy — inscriptions, BRC-20, Runes, the businesses built on them — hardens into a constituency that will fight any future restriction. So “we can always bound this later” can quietly become “we never will,” while the every-node bill keeps stacking. If you genuinely believe Bitcoin’s job is to be money, unbounded data isn’t neutral — it’s mission drift with a compounding cost, and a one-year, self-expiring fork is a defensible way to assert the principle and buy time. Even the aggressive 55% node-enforced mechanism has a charitable reading: after 2017, plenty of people concluded miners shouldn’t hold a veto over rules users actually want. That’s not nothing.

I take all of that seriously. Here is why it still doesn’t get you to shipping 110, and it doesn’t get you there first.

The externality is real; 110 just isn’t a fix for it. Undecidability means the data re-encodes — Todd already proved it — so you pay the entire price (chain-split risk, stranded presigned transactions, a censorship lever welded into consensus) and the JPEGs keep coming, now in forms that are harder to prune. You do not spend your scarcest resource on a tool that doesn’t work. If the externality is the real worry, aim at the thing that actually sets the economics: the witness discount that prices bulk data at a quarter rate is a lever you can turn without a content rule, and relay policy plus a genuinely decidable, non-confiscatory consensus change — if one can be designed — is where that fight belongs. The urgency is legitimate. 110 is still the wrong weapon, and first is still the wrong slot.

And there’s a simpler rebuttal that doesn’t even touch the tech: a thin minority does not get to decide what’s urgent for everyone else. Urgency is the oldest lever every top-down system pulls — this is an emergency, we have to act now, the normal rules don’t apply. And this urgency is manufactured — a handful of familiar voices working to turn a contested, easily-circumvented proposal into a fire drill. A proposal sitting at roughly 1% signalling that declares a network-wide emergency and forces compliance by rejecting everyone else’s blocks isn’t defending Bitcoin’s ethos — it’s inverting it. Bitcoin is rules without rulers; a single-digit minority appointing itself the arbiter of what’s urgent, and pointing a chain split at the network to enforce it, is the disease, not the cure. Let it work and Bitcoin is no better than the fiat system it exists to replace — you’ve just swapped central bankers for a different small group with a finger on the button. “Money, not data” is a real principle. But you win it the Bitcoin way: by convincing people, not by declaring an emergency and coercing them.

Do the boring one first

Soft-fork activation is a coordination muscle, and it atrophies. We have not shipped one since Taproot in 2021 — five years. Lead with 110 and you don’t just spend consensus, you poison it: you re-run the 2017 SegWit trauma, harden the camps, and make even the comparatively uncontroversial cleanup harder. Sitting at 1% signalling, 110 is already a live demonstration of how not to do this.

So do the boring, objective fix first. Ship 54. Prove the network can still agree on anything. And if you want to spend real political capital, spend it on something that gives people more, not less — CTV, CheckSigFromStack, vaults, programmable custody. That’s a fork worth the fight. A one-year censorship experiment parked at 1% is not.

Because here’s what the fork reflex misses: when the only tool you reach for is a soft fork, every problem starts to look like one. The data you’re worried about doesn’t get legislated away with a 55% gun to the network’s head — you answer it by making the chain too big to fork: keep your UTXOs, run your node, grow the economic mass until no minority can bully it. Bitcoin is money, not a hard drive, and I’ll die on that hill. But you defend that by fixing what’s actually broken, shipping what actually adds power, and building the network too big to capture — not by handing a thin minority a censorship lever and calling it an emergency.