Dossier 04 Source-led history · Edition 1.0
The Bitcoin Block Size War: SegWit, UASF and the 2017 Forks
The block-size war was simultaneously a capacity dispute and a dispute over authority. Proposals, miner signals, company agreements, node software, and market choices mattered in different ways; collapsing them into a single vote erases the central lesson.
In this dossier
At a glance
Verified record
| Date or height | Record | Mechanism | Verified outcome | Source |
|---|---|---|---|---|
| 22 June 2015 | BIP101 assigned | Hard-fork proposal | Proposed an 8 MB initial limit followed by scheduled growth; it was not deployed on Bitcoin mainnet. | [1] BIP 101 |
| 15 November 2016 | SegWit signaling window opened | BIP9 version bit 1 | BIP141 specified a 95% threshold within a 2,016-block period before timeout. | [3] BIP 141 |
| 23 July 2017 / block 477,120 | BIP91 active | Miner-enforced reduced threshold | Participating miners began rejecting blocks that did not signal compatibility with the existing SegWit deployment. | [6] Block 477,120 |
| 1 August 2017 | Bitcoin Cash split | Incompatible hard-fork rules | A separate chain began accepting larger blocks under different consensus rules. | [9] Grayscale fork chronology |
| 9 August 2017 | SegWit locked in | BIP9 state transition | The BIP141 deployment entered locked-in state before activation one retarget period later. | [3] BIP 141 |
| 24 August 2017 | SegWit active | Node-enforced soft fork | SegWit became active at block 481,824. | [8] Block 481,824 |
| 8 November 2017 | SegWit2x suspended | Project announcement | Backers cancelled the planned two-megabyte hard fork before its target height. | [9] Grayscale fork chronology |
A capacity limit became a dispute about who should bear scaling costs
Bitcoin’s one-megabyte block limit constrained the serialized transaction data that miners could include. Larger-block advocates emphasized more base-layer throughput and lower congestion. Opponents emphasized the bandwidth, storage, and validation burden imposed on independently operated nodes. The disagreement was not whether Bitcoin should serve more users, but which resources should scale and which decentralization risks were acceptable.
BIP101 proposed an incompatible increase beginning at eight megabytes with scheduled growth. Other proposals varied in size, timing, and activation. Because nodes enforcing the old rule reject oversized blocks, a direct increase required a hard fork: users and infrastructure would need compatible software or the network could separate into persistent chains. The technical deployment method therefore carried a governance consequence.
SegWit changed transaction serialization and block accounting
Segregated Witness moved signature and related witness data into a new serialization committed through the coinbase transaction. It defined a witness transaction identifier and replaced the simple byte limit for upgraded nodes with a four-million-unit weight rule: base size multiplied by three, plus total size. Older nodes could continue treating the new outputs and blocks under backward-compatible rules.
The change increased effective capacity and fixed involuntary transaction malleability for SegWit spends, supporting dependable chains of unconfirmed transactions such as payment channels. It did not make block space unlimited, and its capacity gain varies with transaction composition. The soft-fork form also meant upgraded nodes could enforce additional restrictions without requiring every older node to understand witness data.
Miner signaling measured coordination, not unrestricted legislative power
BIP9 assigned SegWit a version bit and required 95% signaling during a 2,016-block period to lock in before a timeout. Signaling remained below that threshold for months. The stall was interpreted differently by participants: as miner opposition, bargaining leverage, technical caution, or evidence that a small number of pools possessed an effective veto under the chosen deployment method.
A version bit is information in a miner-produced header. Its effect comes from software interpreting it under a specified state machine. Signaling can coordinate deployment, but it does not permit miners to make an otherwise invalid block acceptable to a fully validating node. Confusing a readiness mechanism with final authority became one of the conflict’s central conceptual errors.
The New York Agreement and BIP148 advanced rival theories of coordination
A group of companies and miners announced an agreement to support SegWit followed by a two-megabyte hard fork, commonly called SegWit2x. The signatories represented substantial infrastructure and reported hash power, but no agreement could automatically update software chosen by every node operator. The plan translated institutional coordination into a proposed release and future fork, not a binding rule for the entire network.
BIP148 proposed that participating nodes reject blocks failing to signal for SegWit after 1 August. Its leverage depended on adoption and the possibility that miners would prefer compatibility with those users. The proposal likewise had no central enforcement office. It embodied a different route to coordination: users voluntarily running stricter software and accepting the economic and chain-split risks that followed.
BIP91 brought signaling into alignment before the threatened deadline
BIP91 used a lower miner-signaling threshold and required participating miners to reject blocks that did not signal compatibility with the existing SegWit deployment. It locked in during July. The resulting behavior caused BIP141’s original threshold to be reached, allowing SegWit to lock in and then activate at block 481,824 on 24 August.
Agreement about SegWit did not restore agreement about larger blocks. Bitcoin Cash began a separate incompatible chain on 1 August. The planned SegWit2x hard fork was suspended in November when its organizers concluded that sufficient consensus for a clean upgrade had not emerged. Different rule sets could survive as separate assets, but neither branding nor hash-power claims could force all users to value or validate them identically.
Bitcoin governance is a sequence of constrained choices, not one ballot
Developers can write proposals and software but cannot install it on independent machines. Miners choose candidate transactions and supply proof-of-work but receive value only for blocks accepted by the network they intend to serve. Businesses choose integrations and naming. Node operators choose validation rules. Holders and markets assign economic value among resulting assets. These roles overlap socially but remain technically distinct.
The 2017 outcome should therefore be narrated with verbs precise enough to identify each mechanism: proposed, implemented, signaled, enforced, mined, listed, and valued. Saying simply that ‘the community decided’ or ‘miners voted’ conceals both conflict and procedure. The most durable result of the episode was not universal agreement about scaling, but a public demonstration that incompatible constituencies could separate rather than compel one rule set.
The activation sequence
The sequence separates proposal publication, signals, node enforcement, and persistent forks.
- BIP101
A hard-fork proposal specified an 8 MB initial limit and future increases.
- SegWit proposal
BIP141 documented witness commitments, transaction identifiers, weight, and deployment.
- BIP9 window
Miner signaling for the SegWit deployment began.
- New York Agreement
Companies and miners announced support for SegWit followed by a two-megabyte hard fork.
- BIP91 active
At block 477,120, the reduced-threshold miner-enforcement mechanism began coordinating signaling for BIP141.
- Bitcoin Cash
An incompatible larger-block chain separated.
- SegWit active
Upgraded nodes enforced BIP141 beginning at block 481,824.
- SegWit2x suspended
Organizers cancelled the planned hard fork before its target height.
Evidence discipline
What the record establishes
BIP141 used BIP9 bit 1 with a 95% threshold and activated at block 481,824.
[3] BIP 141 · [8] Block 481,824BIP91 specified an 80% threshold over a 336-block window and required bit-1 signaling while active.
[5] BIP 91Bitcoin Cash split on 1 August 2017 and SegWit2x was suspended in November.
[9] Grayscale fork chronologyThe conflict is best modeled as interaction among several constrained constituencies rather than a vote by one electorate.
[3] BIP 141 · [4] BIP 148 · [5] BIP 91 · [9] Grayscale fork chronologyLimits
What this record does not establish
- Reported company, node, or hash-power support is a time-bounded estimate and should not be treated as a census of users.
- ‘UASF caused SegWit’ and ‘miners activated SegWit’ are both monocausal summaries of a multi-stage sequence.
- Bitcoin Cash and SegWit2x were distinct projects: the former launched a persistent chain; the latter planned a separate November fork that was suspended.
Source register
Primary records and technical references
Retrieved and reviewed 8 August 2026- BIP 101Bitcoin Improvement Proposals · primary proposal
The proposed initial block limit, growth schedule, and activation design.
Open source - BIP 9Bitcoin Improvement Proposals · primary specification
The version-bits state machine used by the original SegWit deployment.
Open source - BIP 141Bitcoin Improvement Proposals · primary specification
SegWit serialization, identifiers, witness commitment, weight rule, and original deployment parameters.
Open source - BIP 148Bitcoin Improvement Proposals · primary proposal
The user-activated enforcement rule and its planned 1 August 2017 start.
Open source - BIP 91Bitcoin Improvement Proposals · primary specification
The reduced signaling threshold and miner enforcement used to coordinate SegWit lock-in.
Open source - Block 477,120Blockstream block explorer · primary blockchain record
The header record at the height where BIP91 enforcement became active.
Open source - Potential network disruptionBitcoin.org · primary contemporaneous warning
Participants publicly anticipated chain-split and confirmation risks around 1 August.
Open source - Block 481,824Blockstream block explorer · primary blockchain record
The block height and header record at which SegWit became active.
Open source - Grayscale fork chronologyU.S. Securities and Exchange Commission EDGAR · primary regulated filing
A contemporaneously accountable corporate chronology of Bitcoin Cash, SegWit activation, and SegWit2x suspension.
Open source
Cite this dossier
A stable, versioned reference
Degrees of Satoshi editorial project. “The Bitcoin Block Size War: SegWit, UASF and the 2017 Forks.” Degrees of Satoshi, version 1.0, 8 August 2026. https://degrees-of-satoshi.pages.dev/history/bitcoin-block-size-war/
Contemporary primary records are preferred. Protocol behavior, business failures and government policy are treated as separate evidence categories. Interpretive claims are explicitly bounded; corrections should cite a source at least as strong as the record being revised.
Read the research standards