"Don't Be Hasty: BIP-110 Is the Wrong Way to Change Bitcoin"
July 07, 2026
Treebeard had a rule for big decisions: don't be hasty. The Ents took three days of Entmoot to agree that Saruman was a problem, and Saruman had been burning their trees for years. That pace looks like weakness until you notice the Ents got the decision right, acted once, and never had to walk it back.
Bitcoin governance is supposed to be Entish. BIP-110 is not, and that is my problem with it.
Where I stand, since this debate sorts people into tribes within the first sentence: I am a conservative bitcoiner. I run my own node. I believe the timechain exists to settle money, and I wince at every jpeg stuffed into witness data. When Bitcoin Core v30 raised the default OP_RETURN relay limit from 83 bytes to 100,000, I thought it was a mistake in judgment and a worse mistake in signaling. The people angry about spam are angry about something real.
And I still want BIP-110 to fail.
What It Does
BIP-110, the Reduced Data Temporary Softfork, adds seven consensus rules for 52,416 blocks, about one year. The two headline rules cap new output scriptPubKeys at 34 bytes (83 for OP_RETURN) and cap data pushes and witness elements at 256 bytes. Those take limits that lived in relay policy for a decade and promote them to block validity.
The other five reach further:
- Spending outputs with undefined witness or tapleaf versions becomes invalid.
- Any Taproot annex makes the witness invalid.
- Taproot control blocks over 257 bytes are invalid, which caps a taptree at 128 script leaves.
- Tapscripts containing OP_SUCCESS* opcodes are invalid, even unexecuted ones.
- Tapscripts that execute OP_IF or OP_NOTIF are invalid, whichever branch runs.
UTXOs created before activation stay exempt. Everything created after activation lives under the new rules until they expire.
Look at the shape of that list. Two rules target spam. Five rules fence off the mechanisms Taproot left open on purpose: undefined versions and OP_SUCCESS opcodes are the exact doors future soft forks walk through, and the annex is reserved space for upgrades we haven't designed yet. This is not a spam filter. It is a moratorium on script flexibility with a spam filter attached.
The Grievance Doesn't Match the Remedy
The case for BIP-110 leans hard on the Core v30 change. I share the objection to v30, so let me be precise about what it was: a change to a relay default. Relay policy governs what your node gossips and what a miner's template includes. It has never governed what a valid block contains. Miners included nonstandard transactions before v30, and node operators who hated the new default could set their own datacarrier limit, run Knots, or patch Core the day it shipped. Many did. I took the easiest route of all and stayed on v29.3, so the new default has never touched my node. My node, my rules, your node, yours. That per-node sovereignty is the design working as intended.
BIP-110 answers that config default with a network-wide validity rule binding on every node and every miner. The asymmetry should bother you: it is a zoning dispute answered with a constitutional amendment. If the complaint is that Core changed a default without community consensus, the remedy cannot be a consensus change without community consensus. You do not defend a norm by breaking a bigger one.
The Activation Math Is the Tell
Every major soft fork in Bitcoin's history demanded overwhelming miner readiness. SegWit required 95% signaling. Taproot locked in at 90% after about three and a half years of review, and it activated without a single orphaned block because by then nobody was against it.
BIP-110 sets its threshold at 55%: 1,109 of 2,016 blocks in a retarget period. It then adds mandatory signaling in the period before lock-in, blocks 961,632 through 963,647, during which enforcing nodes reject any block that fails to signal. Lock-in happens no later than block 963,648, and activation lands no later than about September 1. The BIP's stated rationale for the lowered bar is that the fork is urgent and temporary.
Sit with that number. A 55% activation means up to 45% of hashrate could be mining blocks that enforcing nodes reject. That is not a soft fork riding overwhelming consensus. That is a coin flip with a chain split on the losing face. The grandfathering makes a split worse, since coins created after the divergence would be valid on one chain and unspendable on the other, and no expiry date reconciles two histories once they fork. "Temporary" describes the rules. It does not describe the damage.
Meanwhile, as I write this, miner signaling hovers between 0.3 and 0.5 percent of network hashrate, a few blocks a day from small pools, with no major pool committed. Knots nodes account for a fifth or more of reachable nodes in some snapshots, so the enthusiasm is real. The hashrate is not following, and the proponents know this. A proposal with mandatory signaling and a lowered threshold, launched with support measured in fractions of a percent, is not built to activate. It is built to force everyone to declare a side, and the community it is splitting, loud as it is online, is a small one in global terms. Bitcoin does not have bitcoiners to spare for a schism over 83 bytes.
The Collateral Damage Lands on Builders
The people hit hardest by the five extra rules are not spammers. Spammers adapt in a weekend; the BIP itself admits chunked and steganographic data still gets through. The people who cannot adapt in a weekend are the ones building on Taproot's flexibility.
BitVM depends on taptrees far past 128 leaves, and the BIP acknowledges it breaks during the enforcement period. LN-symmetry designs for Lightning use the annex, which becomes invalid outright. Miniscript wallets emit tapscripts with OP_IF branches today, in production. Ark builds its virtual UTXOs from trees of pre-signed Taproot transactions, the kind of construction that has to reevaluate every byte against rules two, five, and seven. Some of this is shipping code and some is whiteboard work, but a year of consensus-layer uncertainty taxes both, and "wait until it expires" is a strange thing to tell the projects trying to scale Bitcoin payments while blockspace fills with the spam this BIP fails to stop.
Don't Be Hasty
Taproot is the pattern worth defending: years of public review, near-unanimous support, a boring activation. Slow, then complete. BIP-110 inverts each piece. It lowers the threshold because it lacks the support, mandates signaling because it lacks the miners, and waves off scrutiny because the rules expire. It also introduces something Bitcoin has never had: consensus validity that depends on when a UTXO was created, under rules with a sunset clause. Whatever you think of spam, adding that precedent to fight jpegs is a poor trade.
I will not signal for it, and my node will not enforce it. My node runs a restrictive relay policy as it stands, and I would welcome better policy tooling, saner Core defaults, and a fee market that makes data storage pay full freight. Spam is ugly. It is also survivable, and it gets priced out or it funds the miners securing my coins. A contentious split does neither.
The Ents went to war once, when the whole moot agreed. Then they tore Isengard down to the foundations in a night. That is how consensus change should work in Bitcoin: hard to start, impossible to stop. BIP-110 is the opposite, easy to start and impossible to control, and I want no part of it.