Timechain Wiki

SegWit upgrade

12 min read

Segregated Witness — activated as a soft fork on 24 August 2017 at block 481,824 — separates witness data (signatures and scripts) from transaction data, fixes transaction malleability, and effectively increases base-layer throughput via a 4× witness discount. The malleability fix is the load-bearing precondition for deployable Lightning channels: without it, the partially-signed transaction chain that defines a channel is fragile against third-party tampering. The witness discount reframes block capacity from a 1 MB hard limit to a 4 million weight unit limit, with witness bytes counted at 1/4 weight — an effective ~1.7-2.2× throughput increase depending on transaction mix, alongside new bech32 address formats ( bc1q... v0 native SegWit, then bc1p... v1 Taproot after BIP341) with lower mistyping risk and smaller on-chain footprint. Activation followed the Block Size Wars and the UASF (BIP148) coordinated effort, and adoption is now near-universal — SegWit is the base-layer scaling enabler, the precondition for Lightning specifically and off-chain scaling generally.

Why this note matters

SegWit occupies a structurally distinctive position in Bitcoin’s scaling story. It is not a Layer-2 system itself; it is the base-layer protocol upgrade that made deployable Layer-2 systems possible. Lightning channels depend critically on stable transaction identifiers between channel participants; without the malleability fix, the partially-signed commitment-transaction chain that defines a Lightning channel is fragile against third-party tampering. SegWit removed that blocker.

The witness discount additionally functions as base-layer throughput expansion — modest in scale (1.7-2.2× effective increase rather than the 4× theoretical maximum) but real. For users and applications that need on-chain settlement, SegWit-format transactions are cheaper and more efficient than legacy-format equivalents.

Outside the immediate scaling dimension, SegWit’s activation was the resolution moment of the Block Size Wars (2015-2017). It established that contentious soft-fork upgrades could be coordinated through user-activated mechanisms (UASF / BIP148) when miner signaling alone was insufficient. That governance precedent shapes ongoing Bitcoin protocol evolution.

What SegWit does

SegWit is the conventional name for the bundle of BIPs that activated as a single soft-fork upgrade in August 2017. The core BIPs:

  • BIP141 — Segregated Witness (Consensus layer): defines the witness data structure, the new transaction-serialization format, and the witness commitment in coinbase transactions.
  • BIP143 — Transaction Signature Verification for Version 0 Witness Program: defines the new sighash algorithm for SegWit inputs, fixing the O(n²) sighash-bytes-hashed complexity that affected legacy signature verification.
  • BIP144 — Segregated Witness (Peer Services): defines the network-protocol changes for relaying SegWit transactions.
  • BIP173 — Base32 address format for native v0-16 witness outputs (bech32): the new address format for SegWit outputs.
  • BIP141’s effective-block-size change: the witness-discount accounting that replaced the 1 MB block-size limit with a 4 million weight unit limit.

The mechanism. Pre-SegWit, every transaction’s signatures were part of the data that hashes to produce the txid. This meant any third party who could modify the signature encoding (without invalidating the signature itself — for example, by re-encoding the DER signature with extra padding) could change the txid before the transaction was confirmed. The transaction was still valid, but downstream protocols that referenced the txid (like Lightning’s commitment-transaction chain) would break.

SegWit segregates the witness data — signatures and scripts — from the txid hash computation. The txid is computed only over the non-witness portion of the transaction (inputs, outputs, locktime, version). A separate witness txid (wtxid) commits to the full transaction including witnesses. Because the txid no longer includes signature data, third-party signature-encoding tampering cannot change the txid.

The malleability fix

Transaction malleability had been a known vulnerability since at least 2010. Mt. Gox notably claimed malleability as a contributing factor in its 2014 collapse (see Mt. Gox), though independent investigation found the malleability framing exaggerated relative to operational mismanagement.

The blocker for Layer-2 specifically. The Lightning Network as designed by Joseph Poon and Thaddeus Dryja (white paper 2015; first deployable in 2017-2018) requires participants to construct chains of unconfirmed transactions: a funding transaction creates the channel, and commitment transactions update channel state between participants. Each commitment transaction’s input refers to the funding transaction’s output by txid. If the funding transaction’s txid can be modified by a third party between when the participants construct the commitment chain and when the funding transaction confirms, the commitment chain becomes invalid — and the channel cannot be safely opened.

SegWit’s segregation of witness data from txid computation closes the malleability vector for any output that uses a SegWit script. Lightning channels use SegWit funding outputs by construction; this is the precondition that made deployable Lightning possible.

Schnorr/Taproot extension. The 2021 Taproot soft fork (BIP340/341/342) extended SegWit’s witness-discount accounting to v1 witness programs and introduced Schnorr signatures with their own anti-malleability properties. Lightning’s eventual upgrade to PTLCs (point-time-locked contracts) over HTLCs depends on Schnorr; the SegWit → Taproot lineage is continuous.

The witness discount and effective block size

Pre-SegWit, Bitcoin’s block size was capped at 1 MB by a consensus rule. SegWit replaces that with a weight limit: 4 million weight units per block, where:

  • Non-witness data (inputs, outputs, locktime, version) is counted at 4 weight units per byte
  • Witness data (signatures, scripts) is counted at 1 weight unit per byte

In practice, a typical SegWit transaction is roughly 30-40% witness data. The effective block-size increase ranges from ~1.7× (mostly P2PKH legacy-output spends) to ~2.2× (mostly P2WPKH native-SegWit-output spends). The theoretical 4× maximum applies only if blocks consisted entirely of witness data, which is not achievable.

The fee-discount implication. Per-byte fee bidding now applies to weight rather than raw bytes. A SegWit transaction with N bytes of witness data pays effectively N/4 weight for that data — making SegWit-format spends meaningfully cheaper than legacy-format spends at any given fee rate. This is a direct economic incentive for wallet upgrades and address-format migration.

The bech32 address family

SegWit introduced a new address format (BIP173 bech32 for v0 SegWit; BIP350 bech32m for v1 Taproot) with several improvements over the legacy base58check format:

  • Error detection. Bech32 uses a BCH code that can detect any 4-character substitution and locate most typos. Base58check uses a simpler checksum that catches fewer error patterns.
  • Lower mistyping risk. Bech32 uses a 32-character alphabet that excludes visually similar pairs (no 1 and l; no 0 and O).
  • All-lowercase or all-uppercase. Bech32 is case-insensitive but encoded uniformly to avoid mixed-case confusion.
  • Shorter on-chain encoding. SegWit outputs (P2WPKH, P2WSH, P2TR) encode more compactly than legacy P2PKH/P2SH equivalents.

The address-format lineage. Bitcoin’s address formats evolved through:

  • P2PKH (legacy): addresses starting with 1... — base58check.
  • P2SH (BIP16, 2012): addresses starting with 3... — base58check; later wrapped SegWit (P2SH-P2WPKH and P2SH-P2WSH) was a transitional compatibility pattern.
  • P2WPKH / P2WSH (BIP141, 2017): native SegWit v0; bech32 addresses starting with bc1q....
  • P2TR (BIP341, 2021): Taproot v1; bech32m addresses starting with bc1p....

See Bitcoin addresses (Technical foundations) for the full address-format treatment; this note treats bech32 only as the SegWit-specific consequence.

Activation history — UASF and the Block Size Wars resolution

SegWit’s activation followed two years of acrimonious dispute over how Bitcoin should scale. The Block Size Wars (2015-2017) pitted two camps:

  • Small-blockers favored off-chain scaling via SegWit and Lightning while preserving small base-layer blocks (1 MB at the time) to preserve node decentralization.
  • Big-blockers favored direct base-layer scaling by increasing the block-size limit (variously to 2 MB, 8 MB, or up to 32 MB depending on the specific proposal).

SegWit was the small-blocker technical proposal. By mid-2017, miner signaling for SegWit activation had stalled near the 95% threshold required under BIP9 version-bits activation. The pro-SegWit user-and-developer community responded with BIP148, a User-Activated Soft Fork (UASF) proposal that committed compatible nodes to reject any block from 1 August 2017 onward that did not signal SegWit readiness.

The miners’ counter-move was the New York Agreement (NYA) — a private agreement among some miners and large industry participants to activate SegWit followed by a 2 MB block-size increase (“SegWit2x”). The 2 MB increase ultimately failed to deploy after community resistance to the second leg of the plan; SegWit itself activated cleanly on 24 August 2017 at block 481,824.

The fork outcome. Big-blocker dissent precipitated the Bitcoin Cash fork on 1 August 2017 (block 478,558 on the new chain), creating BCH as a separate cryptocurrency with a larger block-size and no SegWit. The Bitcoin Cash chain has subsequently fragmented further (Bitcoin SV in 2018; various smaller forks). See Bitcoin forks - History for the full fork-history treatment and Block Size Wars - History for the historical-narrative chronicle.

The governance precedent. The UASF activation pattern established that contentious soft forks could be activated by economic-node consensus when miner signaling alone was insufficient. This precedent shapes ongoing protocol-evolution debates; see OP_CAT and the covenants programmability debate and BIP-300 and the Drivechains debate for current-era applications.

Adoption and deployment state

SegWit adoption was initially slow. Major exchanges and wallets took 6-18 months after activation to add native SegWit support; some held out for years. As of 2026, SegWit and Taproot together account for the substantial majority of Bitcoin transaction outputs and inputs, with legacy P2PKH/P2SH still in use primarily by older wallets and entities with backward-compatibility constraints.

The Taproot upgrade (2021). BIP340/341/342 extended SegWit’s witness-discount accounting to v1 witness programs and introduced Schnorr signatures, MAST-style script trees, and the key-path-spend / script-path-spend disjunction. Taproot’s witness discount remains 4× (witness bytes at 1 weight each); the Taproot upgrade did not change the effective block-size further, only the expressiveness of SegWit-format spends.

The mempool ecosystem post-SegWit. Post-2017 fee-market dynamics presuppose SegWit. Wallets that emit legacy-format transactions pay measurably more in fees than wallets that emit native-SegWit transactions, especially during high-mempool periods. This economic pressure has driven most active wallets to SegWit-format defaults.

Tradeoffs and design choices

Soft-fork backward-compatibility constraint. SegWit was designed as a soft fork so that nodes that did not upgrade could remain on the main chain. The cost of soft-fork compatibility is design complexity: SegWit transactions look like anyone-can-spend transactions to non-upgraded nodes, with the actual witness verification happening at upgraded nodes. The wrapped-P2SH-SegWit (P2SH-P2WPKH and P2SH-P2WSH) transitional format added another layer of indirection to support wallets that could send to P2SH but not yet to native bech32. The complexity is real but the soft-fork-deployability outcome was worth the tradeoff.

Witness-discount magnitude as a contested design choice. The 4× weight ratio is calibrated. Higher ratios (8×, 16×) would increase effective block size further but at the cost of larger blocks-on-disk and higher node-bandwidth requirements. Lower ratios would reduce the throughput gain. The 4× choice was a compromise between scaling and node-decentralization preservation; see Network capacity and fee-market critiques for the analytical critique of base-layer throughput limits including post-SegWit limits.

Address-format proliferation. Three concurrent address formats (legacy, P2SH-wrapped SegWit, native SegWit) plus the Taproot fourth has been a real UX problem for users. Wallet-to-wallet send compatibility has improved but is not universal even in 2026. The cost of soft-fork upgrade paths is a non-trivial address-format management burden. See Bitcoin addresses for the full treatment.

Centralization concerns from UASF precedent. The BIP148 activation depended on a coordinated economic-node-and-user response. Critics have argued that this set a precedent for activating contentious changes via coordinated user action that does not reflect broad consensus. The defense: the precedent applies only when miner signaling stalls a clearly-supported upgrade, and the political-economic threshold for coordinated UASF activation is high. See Protocol-evolution constraints and Block Size Wars - History for the substantive engagement.

Substantive analytical critique lives in Network capacity and fee-market critiques (the base-layer throughput limitation including post-SegWit limits) and Protocol-evolution constraints (the broader question of how Bitcoin can or cannot upgrade contested features). Both notes engage the substantive concerns at depth.

Open questions for further development

  • How does the SegWit upgrade pattern apply to future contested soft forks? The OP_CAT and Drivechains debates (see OP_CAT and the covenants programmability debate and BIP-300 and the Drivechains debate) are testing whether the BIP148 UASF precedent generalizes to non-scaling upgrades.
  • What is the long-run trajectory of address-format consolidation? Legacy-format usage is declining but not eliminated; the wallet-and-exchange compatibility burden remains.
  • Does SegWit’s 4× witness discount continue to be the right calibration as hardware costs evolve? A re-evaluation of the witness-discount magnitude could be a future upgrade conversation, but no specific proposal is currently active.
  • How does SegWit interact with proposed covenant-enabling soft forks? Several Layer-2 proposals depend on covenant opcodes that would require additional soft-fork upgrades; the activation-pattern lessons from SegWit inform that conversation.

Canonical sources for this note

Specifications

  • BIP141 — Segregated Witness (Consensus layer), Pieter Wuille / Eric Lombrozo / Johnson Lau (2015): github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
  • BIP143 — Transaction Signature Verification for Version 0 Witness Program, Johnson Lau / Pieter Wuille (2016): github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
  • BIP144 — Segregated Witness (Peer Services): github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
  • BIP173 — Base32 address format for native v0-16 witness outputs (bech32), Pieter Wuille / Greg Maxwell (2017): github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
  • BIP148 — Mandatory activation of SegWit deployment, shaolinfry (2017): github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

Technical references

Historical-context references

Graph View

Backlinks