LOCAL REVIEW EDITION · 19 SEPTEMBER 2026Research scope & limitations ↗

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

A flag day set by users, not miners

BIP148, authored by the pseudonymous Shaolin Fry and created 12 March 2017, specified that from 1 August 2017 until 15 November 2017, nodes running its rules would reject any block that did not signal support for Segregated Witness. The document states the mechanism directly: 'Blocks that do not signal as required will be rejected.' This is a user activated soft fork: the enforcement threshold is chosen and run by whoever operates a validating node and adopts the rule, not by whichever miners agree to signal, which is the opposite of the standard threshold-based signalling BIP141 specified on its own.

The threshold that emerged instead

Before BIP148's flag day arrived, BIP91, authored by James Hilliard and created 22 May 2017, proposed a separate route: miners would enforce signalling for Segregated Witness once 80 percent of a signalling window supported it, a lower bar than the 95 percent that BIP141's own version-bits deployment framework, BIP9, required. BIP9, created 4 October 2015, defines the underlying state machine: a proposal moves through defined, started, locked-in, active and failed states based on measured miner signalling across 2,016-block windows. BIP91 locked in before BIP148's flag day took effect, so the two mechanisms converged on the same outcome without both operating exactly as each had separately proposed.

The boundary: what the episode shows about enforcement

BIP148 was, on its own text, a real risk: had miner signalling not converged in time, nodes running it would have split from any chain that did not comply, producing two networks. The document does not itself record what would have happened in that scenario, and this account should not be stretched into a claim that a split was inevitable or was avoided for any single reason; BIP91's separate, lower threshold is the specific mechanism the record shows arriving first. What the episode does establish is structural: node operators, by choosing which validation rules to run, held real leverage over which chain miners' blocks would count on, independent of miners' own signalling choices.

Questions to carry forward

  • If BIP91's threshold had not been reached before the flag day, what evidence exists about how many nodes were actually prepared to enforce BIP148?
  • Does 'user activated' describe the initiators of a proposal, or does it describe who ultimately enforces it once running?
  • In a future disagreement between node operators and miners, which side's rules would exchanges and payment processors actually follow?

Reading BIP148, BIP91 and BIP9 together separates the threat of a user-driven fork from its resolution: a lower-threshold miner mechanism arrived first, and the harder question of what enforcement by economic nodes can compel when it does not is this episode's real subject.

Sources & reading trail

BIP 148: Mandatory activation of segwit deployment ↗

Specifies the user-activated soft fork flag day and the requirement to reject non-signalling blocks.

Source published: 12 March 2017 · Retrieved: 16 September 2026

BIP 91: Reduced threshold Segwit MASF ↗

Specifies the lower 80 percent miner signalling threshold that locked in ahead of BIP148's flag day.

Source published: 22 May 2017 · Retrieved: 16 September 2026

BIP 9: Version bits with timeout and delay ↗

Defines the version-bits deployment state machine and the 95 percent signalling threshold BIP148 and BIP91 relate to.

Source published: 4 October 2015 · Retrieved: 16 September 2026

Historical sources establish the record; the questions and interpretation are Block Due Diligence’s editorial analysis. This retrospective draft does not imply the site published on the event date.