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 |
| 18 November 2016 / block 439,488 | SegWit entered its first STARTED period | BIP9 version bit 1 | BIP141’s configured minimum median-time-past was 15 November; the first 2,016-block STARTED period began at the next boundary. | [2] BIP 9[3] BIP 141[7] Block 439,488 |
| 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. | [11] 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. | [9] Block 481,824 |
| 8 November 2017 | SegWit2x suspended | Project announcement | Backers cancelled the planned two-megabyte hard fork before its target height. | [12] Segwit2x Final Steps |
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 · [9] 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.
[11] Grayscale fork chronology · [12] Segwit2x Final StepsThe 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 · [10] Bitcoin Scaling Agreement at Consensus 2017 · [11] Grayscale fork chronology · [12] Segwit2x Final StepsLimits
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.
Direct answers
Frequently asked questions
When did SegWit activate on Bitcoin?
SegWit became active at block 481,824 on 24 August 2017. Its configured BIP9 start time had been 15 November 2016, while the first 2,016-block STARTED period began at block 439,488 on 18 November.
Did miners alone decide the Bitcoin block size war?
No single signal constituted authority over all participants. Miner signaling coordinated deployment states, BIP91 changed miner enforcement behavior, users could run BIP148 software, and each fully validating node ultimately accepted or rejected blocks under its own rules.
Did Bitcoin Cash increase Bitcoin’s own block limit?
No. Bitcoin Cash began a separate chain under incompatible rules on 1 August 2017. Nodes enforcing Bitcoin’s existing consensus rules did not treat the new chain’s larger blocks as valid Bitcoin mainnet blocks.
Source register
Sources, datasets and technical references
Retrieved and reviewed 9 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 - Block 439,488Blockstream block explorer · primary blockchain record
The height and header timestamp at the boundary that began SegWit’s first 2,016-block STARTED period.
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 - Bitcoin Scaling Agreement at Consensus 20172017-05-23Digital Currency Group / Medium · primary project announcement
The signatories’ stated commitment to an 80-percent SegWit activation threshold and a two-megabyte hard fork within six months.
Open source - Grayscale fork chronologyU.S. Securities and Exchange Commission EDGAR · primary regulated filing
A publicly filed corporate chronology of the Bitcoin Cash split and SegWit activation.
Open source - Segwit2x Final StepsMike Belshe and Wences Casares and Jihan Wu and Jeff Garzik and Peter Smith and Erik Voorhees · 2017-11-08Bitcoin SegWit2x mailing list · primary project announcement
The organizers’ announcement that they were suspending the planned two-megabyte upgrade because sufficient consensus had not emerged.
Open source
Cite this dossier
A dated, versioned reference
Degrees of Satoshi editorial project. “The Bitcoin Block Size War: SegWit, UASF and the 2017 Forks.” Degrees of Satoshi, version 1.0. Published 8 August 2026; last reviewed 9 August 2026. https://degreesofsatoshi.com/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