SegWit is a Bitcoin protocol upgrade activated on August 24, 2017, that restructures how transaction data is stored by separating digital signature data (witness data) from transaction input data.
Proposed by Bitcoin Core developer Pieter Wuille in BIP 141, the upgrade was implemented as a backward-compatible soft fork that solved several problems at once: it fixed transaction malleability (a bug letting third parties alter transaction IDs before confirmation), effectively increased block capacity from 1 MB to roughly 1.8–2.3 MB through a new “block weight” measurement, and laid the groundwork for Layer 2 solutions like the Lightning Network, which require non-malleable transaction IDs to function securely.
Witness data is moved into a separate structure and discounted in the weight calculation — counting as 0.25 weight units per byte versus 1 full unit for non-witness data.
As of early 2026, roughly 85–90% of Bitcoin transactions include at least one input using this format, with native addresses (“bc1q”) making up the majority share, and Taproot (“bc1p”) accounting for a further 15–20%.
Origin & History
| Date | Event |
|---|---|
| 2011 | Transaction malleability identified as a Bitcoin issue; Mt. Gox later blames it for exchange losses |
| 2015 | Pieter Wuille proposes Segregated Witness at the Scaling Bitcoin conference |
| Dec 2015 | BIP 141 formally proposed by Wuille, Eric Lombrozo, and Johnson Lau |
| May 2017 | New York Agreement (SegWit2x) proposes the upgrade plus a 2MB block size increase |
| Aug 1, 2017 | Bitcoin Cash hard forks from Bitcoin, choosing 8MB blocks instead |
| Aug 24, 2017 | The upgrade activates on Bitcoin mainnet at block 481,824 via user-activated soft fork pressure |
| Nov 2017 | SegWit2x’s block-size hard fork is called off due to lack of consensus |
| 2018–2019 | Lightning Network launches on mainnet, enabled by the malleability fix |
| Nov 2021 | Taproot activates, building on the original script-versioning framework with Schnorr signatures |
| 2024 | Taproot usage briefly spikes above 40%, driven by Ordinals inscriptions and the Runes protocol |
| Early 2026 | Adoption holds steady at 85–90%; Taproot settles to a more organic 15–20% as speculative activity cools |
How It Works
| Aspect | Legacy (Before) | After the Upgrade |
|---|---|---|
| Block Limit | 1 MB (hard limit) | 4 million weight units (~1.8–2.3 MB effective) |
| Transaction Malleability | Vulnerable (TXID includes signatures) | Fixed (TXID excludes witness data) |
| Lightning Network | Not possible | Enabled — a hard prerequisite |
| Transaction Fees | Full weight for signature data | Lower — witness data discounted ~75% |
| Address Format | 1… (P2PKH) or 3… (P2SH) | bc1q… (native, Bech32) |
| Script Versioning | Difficult to upgrade | Built-in version field enabled Taproot |
| Fork Type | N/A | Soft fork (backward compatible) |
Address format evolution:
- Legacy:
1A1zP1...(P2PKH) - Wrapped:
3J98t1...(P2SH, compatibility shim — now declining) - Native:
bc1qw50...(Bech32, BIP 84) - Taproot:
bc1pw50...(Bech32m, BIP 350)
In Simple Terms
- Reorganizing the filing cabinet: Instead of keeping the signature stapled to the transaction data, the protocol separates it into its own section so the transaction ID is based only on the core data, not the signature.
- Fixes malleability: Before this change, someone could alter a valid transaction’s signature (without invalidating it) and change its ID, a real problem for anything tracking transactions by ID, including Lightning.
- Effective capacity increase: By discounting witness data to 25% of its actual weight, blocks can hold noticeably more transactions without raising the literal size limit.
- Enabled Lightning: Lightning needs transaction IDs that can’t change after creation — this fix made that possible.
- Native and Taproot addresses save the most on fees: If your wallet supports them, “bc1q” or “bc1p” are the best default in 2026: full compatibility, lowest fees.
Real-World Examples
| Scenario | Implementation | Outcome |
|---|---|---|
| Fee reduction | Users move from legacy to native addresses | Roughly 30–38% lower fees for typical transactions |
| Lightning Network | The malleability fix enables Lightning payment channels | Millions of instant, near-zero-fee Bitcoin payments |
| Exchange adoption | Major exchanges implement native-format withdrawals | Exchanges and users both save on cumulative fees |
| Taproot upgrade | Built-in script versioning enables Taproot (2021) | Schnorr signatures, MAST, and Tapscript added to Bitcoin |
| Ordinals/Runes (2024) | Taproot witness fields used to store inscription data | Briefly pushed Taproot usage above 40% of all transactions |
Advantages
| Advantage | Description |
|---|---|
| Malleability Fix | Eliminates third-party alteration of transaction IDs, enabling reliable Layer 2 protocols |
| Increased Capacity | Effectively increases block capacity without changing the literal size limit |
| Lower Fees | Witness data discount reduces effective transaction cost |
| Backward Compatible | A soft fork — non-upgraded nodes can still validate new-format transactions |
| Future Upgrade Path | Built-in script versioning directly enabled Taproot |
Disadvantages & Risks
| Risk | Description |
|---|---|
| Slow Early Adoption | Took roughly 5 years to cross the 85% adoption mark, despite clear fee benefits |
| Complexity | Multiple address formats increase wallet and protocol implementation complexity |
| Not a Full Scaling Fix | Provides a modest capacity increase; doesn’t solve Bitcoin’s fundamental throughput limits |
| Community Division | The scaling debate around this upgrade led directly to the Bitcoin Cash fork |
| Weaker Trust Model for Non-Upgraded Nodes | Nodes that don’t validate witness data rely more on miner honesty for that portion |
Risk Management Tips:
- Use native or Taproot addresses to maximize fee savings.
- Keep wallet software current to ensure full format support.
- Confirm your exchange supports native-format withdrawals before assuming you’re getting the fee benefit.
- For small, frequent payments, pair this with the Lightning Network for the lowest cost and fastest settlement.
Frequently Asked Questions
What’s the difference between SegWit and SegWit2x?
BIP 141 was the soft fork that segregated witness data and activated successfully in August 2017.
SegWit2x was a separate proposal pairing that change with a hard fork to double the block size to 2MB; the hard fork component was cancelled in November 2017 due to insufficient consensus.
Did this upgrade cause the Bitcoin Cash fork?
Indirectly, yes. The pro-big-block faction forked away on August 1, 2017, just weeks before activation, over disagreement on how Bitcoin should scale.
How is Taproot related to this earlier upgrade?
Taproot is version 1 of the same framework. The original built-in script-versioning field was specifically designed to allow future upgrades like Taproot without requiring another fork from scratch.
