This analysis examines the game theory behind BIP-110 (Reduced Data Temporary Softfork) and how its reorg dynamics create economic incentives for miners -- even when BIP-110 hashrate is a minority.
Disclaimer: This document was generated with AI assistance and may contain errors. Corrections and feedback are welcome via gist comments or pull request. This is technical analysis, not financial or investment advice.
The key property of any soft fork is a one-directional validity rule:
- BIP-110 blocks are valid to all nodes. A block that follows BIP-110 rules is a perfectly valid Bitcoin block. Non-BIP-110 nodes accept it without question.
- Violating blocks are only valid to some nodes. A block rejected by BIP-110 nodes (for any reason -- missing signal, violating transaction) is still accepted by non-BIP-110 nodes.
This asymmetry is what makes the reorg dynamics work. The BIP-110 chain can always be adopted by everyone, but the non-BIP-110 chain can only be followed by non-BIP-110 nodes.
BIP-110 proceeds through five states, derived from the BIP9 state machine with extensions for temporary deployments. All transitions align to retarget period boundaries (every 2,016 blocks, ~2 weeks).
| Blocks | State | ~Date | Duration | What happens |
|---|---|---|---|---|
| now -- 961,631 | STARTED | now -- ~Aug 7, 2026 | ~45 days | Voluntary signaling (version bit 4). No blocks rejected. No enforcement. |
| 961,632 -- 963,647 | STARTED + mandatory signaling | ~Aug 7 -- ~Aug 21, 2026 | ~2 weeks | Blocks must set version bit 4 or they are rejected by BIP-110 nodes. Bitcoin Core does not set this bit, so all unmodified Core blocks are rejected. |
| 963,648 -- 965,663 | LOCKED_IN | ~Aug 21 -- ~Sep 4, 2026 | ~2 weeks | Transition period. Mandatory signaling has ended, transaction filtering has not yet started. No blocks rejected. |
| 965,664 -- 1,018,079 | ACTIVE | ~Sep 4, 2026 -- ~Sep 3, 2027 | ~1 year (52 weeks) | Transaction-level filtering enforced (7 heuristics). Blocks with violating transactions rejected. |
| 1,018,080+ | EXPIRED | ~Sep 3, 2027+ | permanent | All BIP-110 rules dropped. Back to status quo. |
Date estimates are based on block 955,194 (June 24, 2026) and assume a 10 min/block average. Real dates shift with hashrate fluctuations.
Source: Parameters from
chainparams.cpp:max_activation_height = 965664,active_duration = 52416(26 retarget periods),threshold = 1109(55% of 2016),bit = 4. State machine logic inversionbits.cpp. Mandatory signaling enforced inContextualCheckBlockHeaderVolatileinvalidation.cpp.
The two enforcement phases -- mandatory signaling and active filtering -- are separated by a ~2 week LOCKED_IN gap where BIP-110 nodes do not reject any blocks. This quiet transition period gives miners time to prepare for the shift from header-level enforcement (must signal) to transaction-level enforcement (must not include violating data).
During this window, BIP-110 nodes reject any block that does not set version bit 4 in the block header -- regardless of what transactions the block contains.
This is critical: Bitcoin Core does not set this bit. No released version of Bitcoin Core knows about BIP-110's deployment, so every block mined by unmodified Core software will be rejected by BIP-110 nodes during this window. The fork trigger here is the block header, not transaction content. A miner running Core would need to either switch to Knots or manually patch their software to set the bit.
Setting the version bit costs nothing at the protocol level (it is a single bit in the block header). However, signaling can be interpreted as explicit support for BIP-110, and pools may weigh reputational, customer, or business consequences of signaling or not signaling. The cost is not purely technical.
During mandatory signaling, if BIP-110 hashrate is substantial, every non-signaling block faces the same reorg race described below. The economic deterrence applies identically: a non-signaling miner risks losing their entire block reward.
Once BIP-110 activates, the transaction-level filtering rules take effect. During this phase, blocks are rejected only if they contain transactions that violate BIP-110's 7 heuristics (oversized OP_RETURN, Ordinals-style inscriptions, etc.).
In this phase, any mining software -- Core, Knots, or otherwise -- that produces blocks with clean transactions will have those blocks accepted by all nodes. The fork trigger is now transaction content, not software version. A miner running Bitcoin Core with standard relay policy will rarely have violating transactions in their mempool in the first place, so most Core-mined blocks would be valid to BIP-110 nodes. However, miners who deliberately include non-standard transactions via custom templates or out-of-band submission would trigger a fork.
After block 1,018,080, the deployment transitions to EXPIRED and all filtering rules are dropped automatically. This is the "Temporary" in "Reduced Data Temporary Softfork."
Whether the rejection is for a missing signal (Phase 1) or a violating transaction (Phase 2), the same race begins:
- Non-BIP-110 nodes accept the block and miners build on it
- BIP-110 nodes reject it and miners continue building from the previous height
- A race begins
The BIP-110 side starts 1 block behind. Both sides mine independently. If the BIP-110 side produces a strictly longer chain, all nodes switch to it because BIP-110 blocks are valid to everyone. The rejected block (and everything built on top of it) gets orphaned.
This is the same mathematical framework Satoshi described in the Bitcoin whitepaper for analyzing double-spend attacks (Section 11), applied to the soft fork case.
For the BIP-110 chain to cause a reorg, it must become strictly longer than the standard chain -- not merely reach parity. At parity (same height), nodes keep whichever block they saw first, which is the rejected block. The BIP-110 chain must gain a net 2 blocks: one to tie, one to overtake.
In a biased random walk where each step favors the majority chain, the probability of gaining +2 from -1 (1 block behind) is:
P(strict overtake) = (q/p)^2
where q = BIP-110 hashrate fraction, p = 1 - q.
This is derived from the Gambler's Ruin problem. Starting at deficit 1, the BIP-110 chain must reach deficit -1 (strictly ahead). Each global block either reduces the deficit by 1 (with probability q, when BIP-110 finds it) or increases it by 1 (with probability p). The probability of ever reaching -1 from +1 in this biased walk is (q/p)^2.
| BIP-110 hashrate | P(rejected block gets orphaned) |
|---|---|
| 10% | 1.2% |
| 20% | 6.3% |
| 30% | 18.4% |
| 40% | 44.4% |
| 50%+ | ~100% |
Note on Satoshi's formula: The whitepaper gives (q/p)^z as the probability of "catching up" from z blocks behind. This is the probability of ever reaching parity, not strict overtake. For an actual reorg, the chain must be strictly longer, giving (q/p)^(z+1). From 1 block behind: parity probability is q/p, strict overtake probability is (q/p)^2. The distinction matters significantly at low hashrate levels.
The clean mathematical model assumes both sides mine independently in a pure race. In practice, network propagation introduces additional dynamics:
- When BIP-110 miners find a competing block, some non-BIP-110 nodes may see it before seeing the rejected block and adopt it first
- Non-BIP-110 miners on those nodes would then mine on the BIP-110 tip, temporarily increasing BIP-110's effective hashrate
These effects push the real-world probability somewhat above (q/p)^2 but below (q/p). The table above represents the conservative baseline.
The economic damage extends beyond the miner who produced the rejected block. Consider this sequence:
- Miner A mines a rejected block at height N+1
- Miner B mines a clean block at height N+2, building on A's block
- Miner C mines a clean block at height N+3, building on B's block
- BIP-110 miners catch up and reorg all three blocks
Miners B and C lose their block rewards (~3.125 BTC each) even though their blocks contained no rule violations. Their only mistake was building on a chain that included a rejected block. At current prices, each orphaned block costs a miner roughly $300,000+.
The deeper the reorg, the more "innocent" miners get caught in the blast radius. This creates social pressure within mining pools: miners have an incentive to pressure other miners to comply with BIP-110 rules, because everyone on the chain pays the price when a reorg hits.
Each miner faces a choice:
During mandatory signaling (Phase 1):
- Signal (set version bit 4): blocks accepted by all nodes. Zero additional reorg risk.
- Don't signal: every block you mine is rejected by BIP-110 nodes, triggering a reorg race with probability (q/p)^2 of losing ~$300,000+ per block.
During active enforcement (Phase 2):
- Mine clean blocks: accepted by all nodes. Zero additional reorg risk.
- Include violating transactions: small fee premium, but block gets rejected by BIP-110 nodes with probability (q/p)^2 of losing ~$300,000+.
At sufficiently high BIP-110 hashrate (roughly 30-40%+), the expected value of producing rejected blocks is negative. At 30% BIP-110 hashrate, an 18% chance of losing ~$300,000 means an expected loss of ~$54,000 per rejected block -- far exceeding any plausible benefit.
Whether this constitutes a stable equilibrium depends on specific conditions: the visible BIP-110 hashrate, the fee premium offered by violating transactions (Phase 2), pool policies, and miner risk tolerance. At low BIP-110 hashrate or during periods of very high data-fee premiums, some miners may rationally accept the orphan risk. The deterrent is strong but not unconditional.
Luke Dashjr has argued that even at low hashrate, the BIP-110 chain will "eventually" overtake the non-BIP-110 chain as difficulty and price adjust. This claim deserves scrutiny.
What is correct: The one-directional reorg pressure is real. Every time a rejected block appears, there is a nonzero probability it gets orphaned. The BIP-110 chain can never be reorged by the non-BIP-110 chain (because BIP-110 blocks are valid to everyone), but the reverse can happen. This asymmetry persists at any hashrate level above zero.
What is overstated: At sustained minority hashrate, the BIP-110 chain cannot win multi-block races reliably. The catch-up probability drops exponentially with depth. A 30% chain that falls 4 blocks behind has only a (0.3/0.7)^5 = 1.5% chance of strictly overtaking. The minority chain does not "eventually" overtake a majority chain in a sustained race -- it falls further behind on average.
What is speculative: The argument that difficulty adjustments and price premiums will shift hashrate toward BIP-110 is game theory, not mathematics. It assumes users will value the BIP-110 chain more, creating a price premium that attracts miners. This is plausible (it played out in the Bitcoin vs. Bitcoin Cash split) but it is not a guaranteed outcome.
The honest summary is: BIP-110 does not need to win sustained chain races to be effective. It wins by making individual rejected blocks economically risky to produce. The mechanism is deterrence, not dominance. But the strength of that deterrent depends on enforcing hashrate, fee premiums, propagation behavior, and whether the BIP-110 branch merely catches up or actually overtakes.
-
For miners (now): If BIP-110 approaches mandatory signaling with substantial hashrate, the rational choice is to signal. The protocol cost is one header bit. The risk of not signaling is losing blocks.
-
For miners (post-activation): At 30%+ BIP-110 hashrate, the expected value of including violating transactions is likely negative. The rational strategy is to not include them, regardless of your views on BIP-110. At lower hashrate levels, the calculus depends on specific fee and risk conditions.
-
For mining pools: Pools have a fiduciary interest in protecting their miners' block rewards. Producing rejected blocks exposes the entire pool to reorg losses. Expect pools to comply proactively as BIP-110 hashrate grows.
-
For users: BIP-110's economic pressure begins working before activation. Post-activation, the consensus rules provide a hard guarantee for the enforcement period (~1 year).
-
For the network: The soft fork asymmetry means BIP-110 tends toward convergence rather than a permanent chain split -- but only if enough hashpower and economic weight enforce the stricter chain. Unlike a hard fork, where two incompatible chains coexist indefinitely, a soft fork's "invalid" chain is always at risk of being reorged by the "valid" chain.
- BIP-110 Specification
- Bitcoin Whitepaper, Section 11 -- Calculations on attacker catch-up probability
- Bitcoin Knots v29.3.knots20260508 -- Shipped implementation
- BIP-110 Adoption Monitor -- Live signaling data
- BIP-110 Technical Review -- Code-level analysis of the 7 filtering heuristics
- Fork Talk FAQ: BIP-110 -- General overview
Fork Talk -- Open source Bitcoin fork research. No opinion without evidence. No claim without a source.
Changelog: v4 (2026-06-24) -- Added full deployment timeline table with all 5 states (STARTED, mandatory signaling, LOCKED_IN, ACTIVE, EXPIRED) and exact block ranges. Noted the ~2 week LOCKED_IN gap between mandatory signaling and active enforcement where no blocks are rejected. v3 (2026-06-24) -- Restructured to lead with two-phase distinction (mandatory signaling vs active enforcement). Corrected "fork triggered by transaction content, not software version" to only apply to active enforcement phase. Noted that Bitcoin Core does not set version bit 4. v2 (2026-06-24) -- Corrected probability table from (q/p) to (q/p)^2 for strict overtake requirement. Softened Nash equilibrium claim to conditional. Added propagation effects caveat.