Activation and fork paths

The parameters are fixed

The mainnet deployment parameters are compiled into the client. There is no supported bitcoin.conf option to tune them on mainnet.

A qualifying signal needs both the normal versionbits top pattern 001 and bit 4 set. In bit terms, a block version v qualifies when (v & 0xe0000000) == 0x20000000 and (v & 0x10) != 0. Setting bit 4 with a different top pattern does not count.

The states

The deployment moves through a small set of states. State changes occur only at 2,016-block boundaries. Reaching the threshold in the middle of a period has no immediate effect: at the next boundary the state becomes LOCKED_IN, and one complete period after that it becomes ACTIVE.

Interactive figure slot BIP 110 Era Map figure pending

The start-time condition first made BIP-110 STARTED at height 927,360, so the deployment has been in the voluntary STARTED state for many periods already.

The mandatory-signalling subphase

The mandatory interval is the feature that makes BIP-110 different from an ordinary versionbits soft fork.

The mandatory interval is not a separate versionbits state. The RPC continues to report STARTED. A height predicate adds one extra header rule while the state is still STARTED: for blocks 961,632 through 963,647 inclusive, every accepted BIP-branch header must signal. A non-signalling block in that range is rejected during contextual header validation with reason bad-version-reduced_data. Because the check is on the header, the block body does not even need to be downloaded before the incompatibility is known.

Two consequences follow directly:

• If an earlier period reaches the threshold, the state is already LOCKED_IN when the nominal mandatory interval arrives, and the mandatory rule is skipped entirely. It is skipped, not merely made easier: non-signalling headers are valid on that early path.
• Failure to reach the voluntary threshold does not transition to FAILED. Mainnet has no ordinary timeout. If the branch is still STARTED at 961,632, it proceeds into the mandatory predicate rather than failing.

Only BIP-enforcing nodes apply the mandatory header rule. To an unmodified node, both signalling and non-signalling headers remain valid throughout, which is why this interval is where a split can first become visible.

Figure slot BIP 110 Activation and Fork Paths figure pending

The five key heights

Heights are the clock and are fixed. The dates use the client-source-aligned projection (consistent with the reference client's own comment for the maximum-activation height); they drift with hashrate, and the Live rail recomputes them from the current tip. The technical walkthrough's independent projection, run from a different snapshot block, lands up to four days later for the same heights.

If the voluntary threshold is reached in an early period, the whole schedule shifts earlier and the mandatory interval is skipped. For any voluntary period whose last block is height E, lock-in starts at E + 1, activation starts 2,016 blocks later, and expiry starts at activation plus 52,416. The scenarios article works through the resulting paths.

State is branch-relative

This is the subtle point that a monitoring system must get right. Versionbits state is computed from a specific ancestry, not from a universal wall clock.

A reorganization can replace the signalling history used at a boundary, causing a node to compute a different state on the alternative ancestry. The state can even move backward: if a branch that did not have the required signals replaces one that did, a node following the new branch recomputes an earlier state. A reorg near a period boundary can alter signal counts, the lock-in height, the activation height, and therefore the expiry height. For this reason, any observation of deployment state should be recorded by both block hash and height, so that a later reorg does not make the record ambiguous.

Heights in this article and across the site refer to a given branch, not to a single event that happens everywhere at once, once the histories diverge.

Difficulty does not rescue a small branch quickly

If a split produces a minority BIP branch, the branch does not get an emergency difficulty adjustment. Each branch applies Bitcoin's ordinary 2,016-block retarget with its fourfold adjustment limit.

The mandatory fork point, height 961,632, is itself a retarget boundary. Both children of block 961,631 calculate the same new target from the shared prior period, so a minority BIP branch starts at a difficulty calibrated to the previously shared network. If a fraction f of the former hash rate mines the branch, its initial expected block interval is roughly 10 / f minutes.

The first retarget can lower difficulty by at most a factor of four, so a very small branch may take several slow periods to approach a ten-minute cadence. This is why the projected dates for future heights are only projections: on a minority branch, activation and expiry heights arrive much later in wall time, height-based timelocks advance slowly, and median-time-past follows the branch's own blocks. Fees, prices, and miner movement can change f, so these figures are illustrations, not forecasts.

What to watch

On the Live dashboard:

• Event clock: the current state and which of the five heights is next. Heights are the clock; dates are projections.
• Signalling by period: whether any completed period reaches 1,109, which would move the schedule earlier and skip the mandatory interval. Bit 4 is a header claim, not enforcement.
• Chain tips: during and after the mandatory interval, whether a second tip has appeared and whether nodes disagree about it. Because state is branch-relative, tips are recorded by hash and height.

Sources

This page restates the BIP-110 technical walkthrough sections Activation parameters and state machine (including the state table and the mandatory-interval predicate) and Chain selection, difficulty, and time on a minority branch (the retarget boundary and the fraction-of-hashrate table). It states protocol mechanics only. Which outcome occurs is covered as conditional mechanics in the scenarios article, never as prediction.