BIP-110: the dangers and the merits

On 8 August 2026, at block 961,632, BIP-110 nodes rejected a non-signalling block and followed a different chain. Reporting put the minority chain at roughly 1–2.5% of hashrate: it produced about two blocks and then effectively stalled, while the main chain kept its normal cadence and pulled dozens of blocks ahead within hours. Anyone whose wallet or business followed the minority chain saw confirmations they could not rely on.

Between blocks 961,632 and 963,647 a BIP-110 node rejects any block that does not signal bit 4. Combined with a 55% threshold (instead of BIP 9's 95%) this design does not wait for consensus, it schedules a test of whether consensus exists, and splits the network when the answer is no.

The BIP itself lists the scenario: a P2TR UTXO in a pre-signed transaction that must be confirmed and spent during the one-year window, whose only usable Tapleaf contains OP_IF/OP_NOTIF or sits deeper than 7 levels, with a keypath disabled by a NUMS point. Unlikely, but the author does not claim the risk is zero.

Undefined witness versions, OP_SUCCESS* and the Taproot annex exist precisely as upgrade hooks; the 257-byte control-block cap limits published Taptrees to 128 leaves, which the BIP admits 'could complicate or possibly even impede' advanced contracting such as BitVM. The Miniscript compiler would need changes to stop producing now-invalid Tapleaves.

The BIP concedes it cannot solve spam: data can still be split into 256-byte chunks or disguised as financial data, and non-Bitcoin token schemes are untouched. Critics call that an asymmetric bargain, incomplete filtering in exchange for a new consensus precedent and a real split risk.

Adam Back, who dislikes spam and calls it 'just an annoyance', argued the remedy belongs in local relay policy, not consensus: material changes need broad user consensus, and using consensus to police what others publish sets a precedent that can be reused for other disliked uses. The BIP has a section rejecting the slippery-slope reading; the disagreement was never resolved.

The rules only bind those who run enforcing software. Running BIP-110 code through August 2026 meant risking being forked off the chain that virtually all hashrate, exchanges and custodians followed, a practical, not theoretical, danger for anyone accepting payments.

A sender pays one fee to a miner, while every validating node downloads, verifies and often stores that data forever. Fees compensate miners for producing blocks, not node operators for carrying the cost. Both supporters and prominent critics accept this framing.

Unspent output scripts must live in the UTXO set, which nodes keep on fast storage and cannot prune. Modern payment outputs are 34 bytes or smaller anyway, so rule 1 targets a pattern with, in the BIP's own words, 'a large abuse potential and no benefit'.

The rules would expire automatically after ~52,416 blocks, and every UTXO confirmed before activation keeps its old spending rules for the entire deployment. That is a deliberately narrow blast radius compared to a permanent consensus change.

The author chose seven blunt rules over a cleverer design specifically to keep review time short, and shipped a reference implementation, functional tests (feature_rdts.py, feature_reduced_data_utxo_height.py) and JSON transaction test vectors.

The specification contains a Tradeoffs section that admits BitVM-style contracting, some Miniscript constructions and future upgrade hooks may be constrained, and states plainly that funds could in theory be frozen or lost in narrow edge cases.

Even critics note the episode turned an abstract question, can a minority impose consensus rules? into a measurable, public experiment with a clear answer.