Timechain Wiki

How upgrades happen

12 min read

Bitcoin upgrades happen through a layered social process distinct from how upgrades work in centralized systems. The process spans multiple actor classes — developers (who propose and implement), miners (who signal activation under BIP9/BIP8/Speedy Trial), economic nodes (full-validating nodes operated by users, exchanges, wallets, custodians), and the broader ecosystem whose chain-recognition decisions ultimately determine consensus; no single class can mandate an upgrade. The result is "rough consensus" — broad-but-not-unanimous agreement emerging from extended deliberation. SegWit (2017) required developer proposal, partial miner activation, the UASF threat (BIP148), economic-node coordination, and the BIP91 compromise; Taproot (2021) combined developer proposal, Speedy Trial miner activation, and broad economic-node acceptance. Failed upgrades (Bitcoin Cash 2017 and others) typically produce a chain split. Current covenant debates (OP_CTV, BIP-300) test the mechanism on non-scaling upgrades where historical activation patterns don't directly apply.

Why this note matters

The “how upgrades happen” social process is the operational reality that translates BIP proposals into deployed protocol changes. Understanding the multi-actor coordination required for actual upgrade activation is the precondition for engaging Bitcoin’s broader governance landscape. The mechanism is structurally distinct from how upgrades happen in centralized systems; understanding the distinction illuminates Bitcoin’s specific governance properties.

This note treats the social process; Soft-fork activation mechanisms treats the technical-procedural mechanisms; Governance without governance treats the structural framework.

The actor-class distinctions

Bitcoin’s upgrade process involves multiple distinct actor classes with different roles and incentives:

Developers. Propose protocol changes via BIPs; implement changes in Bitcoin Core and alternative implementations; conduct technical review. Developers have implementation authority but not activation authority. They can propose what changes are technically possible; they cannot mandate that the network adopt them.

Miners. Produce blocks; signal support for soft forks via version-bits signaling. Miners have block-production authority and signaling-coordination role but operate under economic-incentive constraints from economic nodes. A miner who refuses to include valid transactions or who signals contrary to economic-node preference faces structural pressure (reduced economic acceptance of their blocks).

Economic nodes. Full-validating nodes operated by exchanges, wallets, custodians, large holders, and committed individual users. Economic nodes determine which chain to recognize by enforcing specific consensus rules. The aggregate economic-node consensus is what miners signal toward. Economic nodes have validation authority and chain-recognition authority — the ultimate decision-makers in Bitcoin’s governance.

The broader economic ecosystem. End users, smaller node operators, retail exchanges, wallets, and various adjacent participants. This ecosystem provides the demand for Bitcoin and the broader economic context; it shapes which chains have value and which don’t. The ecosystem’s choices are operationally diffuse but structurally important.

Layer-2 operators and Bitcoin-related businesses. Lightning nodes, mining pools, stablecoin issuers (on Liquid), and adjacent infrastructure operators. These actors have specific operational stakes in upgrade decisions; they participate in the coordination process.

Adjacent stakeholders. Regulators, academics, media, and other actors whose decisions don’t directly affect chain consensus but who shape the broader context within which decisions are made.

The hierarchy. Economic nodes are the ultimate decision-makers; miners are economically-motivated coordinators; developers are technical-and-discussion authorities; the broader ecosystem provides the context within which the other actors operate. No actor class has authority over the others; coordination across them is what produces consensus.

The rough-consensus mechanism

“Rough consensus” is the operational concept for how upgrade decisions are made:

The IETF lineage. The term “rough consensus” was originally used in the Internet Engineering Task Force (IETF) for internet-protocol standardization. Dave Clark’s 1992 quote — “We reject kings, presidents and voting. We believe in rough consensus and running code” — captures the philosophy. Bitcoin’s governance adopts and extends this approach.

The Bitcoin-specific characteristics:

  • Multi-venue deliberation. Discussion happens on bitcoindev mailing list, IRC channels, github issues, BIP pull requests, conferences, Twitter/Nostr, and adjacent venues. No single venue is authoritative.
  • Multi-year timeframes. Major upgrades typically have multi-year deliberation periods (Taproot was discussed for 4+ years; covenant proposals have been discussed for nearly a decade).
  • No formal voting. Decisions emerge from discussion patterns; there’s no formal mechanism for tallying votes or aggregating positions.
  • The deliberate-friction-as-feature framing. The process is intentionally slow and consensus-heavy. Quick decisions are structurally distrusted.

The empirical pattern. Rough consensus is achieved when:

  • Developers have implemented and reviewed the proposed change
  • Major implementations include the change
  • Activation-mechanism choice has been negotiated
  • Miners have indicated willingness to signal
  • Economic nodes have indicated willingness to accept

The pattern is non-formalized but operationally identifiable. Observers can typically tell when rough consensus is approaching (multiple supportive signals across actor classes) and when it isn’t (contested signals; absence of major-actor support).

Case study: SegWit 2017

The SegWit activation is the canonical contemporary case study of how upgrades happen under stressed conditions.

The technical proposal. Pieter Wuille and others proposed Segregated Witness in late 2015 as a solution to transaction malleability and as a moderate base-layer scaling mechanism. The technical proposal was relatively clean; the BIP-141/143/144 specifications were well-developed.

The political contention. The Block Size Wars era (2015-2017) produced substantial political conflict about scaling approaches. Small-blockers favored SegWit + Layer-2 scaling; big-blockers favored direct block-size increases. The conflict was substantial — multiple alternative implementations (Bitcoin XT, Bitcoin Classic, Bitcoin Unlimited) competed for adoption.

The activation difficulty. SegWit was deployed via BIP9 in November 2016 with a 95% miner-signaling threshold. By mid-2017, signaling had stalled around 30-40% as some miners (particularly those affiliated with big-blocker positions) refused to signal. The BIP9 mechanism was failing.

The UASF response. BIP148 was proposed in February 2017 as a user-activated soft fork that would force activation by August 1, 2017. Economic-node-running businesses (exchanges, wallets, custodians) increasingly committed to running BIP148.

The BIP91 compromise. James Hilliard proposed BIP91 in May 2017 as a path that would activate SegWit before the BIP148 deadline. BIP91 reduced the signaling threshold to 80% and shortened the lock-in period.

The activation cascade. As August 1 approached, miner-signaling for SegWit climbed from ~50% to >90%. BIP91 reached its threshold July 21, 2017; SegWit locked in August 8, 2017; SegWit activated August 24, 2017.

The Bitcoin Cash fork. Concurrent with SegWit activation, the big-blocker faction forked the network on August 1, 2017 to create Bitcoin Cash. The fork was deliberate; Bitcoin Cash continues to operate as a separate chain with different consensus rules. See Bitcoin forks - History for the historical-narrative treatment.

The structural lessons. SegWit demonstrated:

  • Economic-node consensus can override miner stalling (UASF mechanism)
  • Compromise activation mechanisms can resolve deadlocks (BIP91)
  • Chain-split is the safety valve when rough consensus isn’t achieved (Bitcoin Cash forked rather than the network reaching unified consensus)
  • The activation process is slow and contentious but ultimately resolves

Case study: Taproot 2021

The Taproot activation is the canonical uncontroversial-upgrade case study.

The technical proposal. Pieter Wuille proposed Taproot in 2019 (BIP340 Schnorr signatures, BIP341 Taproot, BIP342 Tapscript). The technical specifications were extensively reviewed.

The community engagement. Multi-year discussion produced broad community support. The technical merits (Schnorr efficiency, smart-contract flexibility, signature privacy) were widely recognized.

The activation-mechanism debate. The principal contested question was LOT=true vs LOT=false (whether mandatory activation should be the default). The eventual compromise — Speedy Trial with LOT=false — was acceptable to both camps.

The activation execution. Speedy Trial began April 24, 2021. Miner signaling reached 100% within a single 2,016-block retargeting period; Taproot locked in June 12, 2021. The 5-month grace period preceded activation on November 14, 2021 (block 709,632).

The structural lessons. Taproot demonstrated:

  • Broad technical support produces clean activation
  • Multi-year deliberation can produce rough consensus
  • Speedy Trial mechanism works when contention is low
  • Compromises on activation mechanism (LOT=true vs LOT=false) can be resolved
  • Major upgrades can happen without forced activation or chain splits when community support is broad

The covenant debates — the contemporary test

The current covenant proposals (OP_CTV / BIP-119; OP_CAT / BIP-347; BIP-300 Drivechains; various others) are testing the rough-consensus mechanism for non-scaling upgrades.

The structural difference from SegWit and Taproot. SegWit and Taproot had widespread support from major actor classes; the contention was procedural rather than substantive. The covenant debates have substantive contention — developers disagree on whether these features should be added at all, not just on activation mechanisms.

The contemporary positions:

  • Pro-OP_CTV / pro-covenants. Argue specific use cases (Ark protocol; vault constructions; eltoo) require covenant capabilities; the engineering case is strong.
  • Pro-OP_CAT / pro-covenants. Similar but more general scripting capability; the use cases overlap.
  • Anti-covenants. Argue that covenants introduce structural complexity that could enable adverse use cases (mining-cartel covenants; censorship-enforcing covenants); the cautionary argument is structural.
  • Pro-incremental progress. Argue for selective covenant deployment (e.g., OP_CTV first, evaluate, then OP_CAT) rather than broad enabling.
  • Pro-status-quo. Argue that current capabilities are sufficient and that new features should require stronger justification.

The empirical state (2026). No covenant proposal has reached rough consensus for activation. Multiple proposals are under active discussion; the OP_CAT discussion has been particularly extensive. Activation mechanisms (UASF for some proposals; Speedy Trial for others) are also under discussion.

The structural test. Whether the rough-consensus mechanism can resolve substantively contested upgrades (rather than procedurally contested upgrades) is the contemporary question. The empirical answer is still developing.

See OP_CAT and the covenants programmability debate and BIP-300 and the Drivechains debate (Controversies) for substantive event-level engagement.

Failed and stalled upgrade attempts

Several upgrade attempts have failed or stalled:

BIP148 alternative deployments. Various proposed UASF deployments for other upgrades (beyond SegWit) have been discussed but not actually deployed. The structural threshold for UASF deployment is high; current debates have not reached that threshold.

Bitcoin Cash. The big-blocker faction’s response to SegWit activation. Operationally a chain split rather than a failed upgrade — Bitcoin Cash continues to operate as a separate network with different consensus rules.

Bitcoin SV. A subsequent fork from Bitcoin Cash (2018). Even smaller community; demonstrates the cascade-of-forks dynamic that contested decisions can produce.

OP_CTV (BIP119). Proposed in 2019; extensive discussion through 2022-2023; has not reached rough consensus. Multiple activation proposals have been discussed and stalled.

Various other stalled or rejected proposals. Many BIPs reach Draft or Proposed status without reaching Final/Active. The pattern is normal — most proposals don’t activate; the mechanism is conservative by design.

The structural conclusion. The rough-consensus mechanism produces a strong status-quo bias. Upgrades that don’t reach broad multi-actor support don’t activate. This is a structural feature of Bitcoin’s governance; it produces stability at the cost of slow evolution.

Counter-arguments and tensions

The slow-evolution critique. Critics argue Bitcoin’s upgrade process is too slow — that legitimate improvements stall for years while the protocol stagnates. Defenders argue slow evolution is the design choice.

The status-quo-bias critique. The rough-consensus mechanism produces a strong status-quo bias. Critics argue this prevents legitimate improvements; defenders argue the bias is appropriate for consensus-critical infrastructure.

The “ossification” framing. Some critics use the term “ossification” to describe Bitcoin’s slow protocol evolution — implying that the protocol has become rigid. Defenders use the same term positively — implying that the protocol has reached a stable equilibrium that should be preserved.

The “developer dominance” concern. Critics argue that developers effectively dominate the rough-consensus mechanism because they control what proposals are considered. Defenders argue that economic nodes ultimately decide which proposals are accepted; developers can propose but not impose.

The “chain-split safety valve” framing. The Bitcoin Cash fork is sometimes cited as evidence that Bitcoin’s governance works (contested factions can fork) and sometimes as evidence that it doesn’t (forks fragment the ecosystem). The right framing depends on context.

Substantive analytical critique of the upgrade-process pattern lives in Protocol-evolution constraints (Criticisms).

Open questions for further development

  • Can the rough-consensus mechanism resolve substantively contested upgrades? The covenant debates are the contemporary test.
  • What is the appropriate role of the UASF mechanism going forward? The BIP148 precedent applies to scaling-related upgrades; its generalization is contested.
  • How does the upgrade process handle long-horizon mandatory upgrades (post-quantum migration)? The mechanism was designed for optional upgrades; long-horizon mandatory upgrades may require different approaches.
  • Will alternative implementations meaningfully shape the rough-consensus dynamics? Bitcoin Core dominance limits multi-implementation governance; whether this changes is uncertain.
  • How does the regulatory environment affect the upgrade process? Developer legal exposure (Tornado Cash precedent) and broader regulatory dynamics shape what developers can practically pursue.

Canonical sources for this note

  • The Blocksize War (book) - Jonathan Bier — canonical historical text on the SegWit activation
  • bitcoindev mailing list archives — primary source for upgrade discussions
  • BIP repository (github.com/bitcoin/bips) — formal proposal record
  • Bitcoin Optech newsletter — coverage of upgrade-mechanism debates
  • Various academic engagement with Bitcoin governance (limited but growing)
  • Mastering Bitcoin - Andreas Antonopoulos — technical reference

Graph View

Backlinks