BIP 141: Segregated Witness (Consensus Layer)
Authors: Eric Lombrozo, Johnson Lau, Pieter Wuille Status: Final Type: Standards Track Created: 2015-12-21 Activated: 2017-08-24 (Block 481,824)
Abstract
Segregated Witness (SegWit) restructures Bitcoin transactions by moving the witness (signature) data into a separate structure. This is deployed as a soft fork, maintaining backward compatibility with older nodes.
Problems Solved
Transaction Malleability: Before SegWit, transaction signatures were part of the transaction ID (txid) calculation. This meant a third party could modify the signature without invalidating it, changing the txid. This was a critical blocker for second-layer protocols like the Lightning Network.
Block Size Limitation: The 1 MB block size limit constrained Bitcoin’s throughput. SegWit introduced “block weight” (maximum 4 million weight units), effectively increasing capacity to approximately 2-4 MB per block without a hard fork.
Signature Verification Scaling: SegWit changed the signature hash algorithm to avoid the quadratic hashing problem, where verification time grew with the square of transaction size.
Key Changes
- Witness data separated from the base transaction structure
- New transaction format with a marker, flag, and witness field
- Block weight replaces block size as the limiting metric (1 byte of non-witness data = 4 weight units, 1 byte of witness data = 1 weight unit)
- Script versioning via witness programs, enabling future upgrades (used by Taproot)
The Block Size War
SegWit’s development and activation occurred during the contentious “Block Size War” (2015-2017). Some community members advocated for a simple block size increase via hard fork, while SegWit proponents favored the soft fork approach. The debate ultimately led to the creation of Bitcoin Cash (BCH) in August 2017, which chose the hard fork path.
SegWit was activated via BIP 9 signaling on August 24, 2017, at block height 481,824.
Significance
SegWit is widely considered the most important Bitcoin protocol upgrade after the initial release. It:
- Enabled the Lightning Network and other Layer 2 solutions
- Introduced script versioning, paving the way for Taproot (BIP 341)
- Resolved a fundamental design flaw (transaction malleability) without breaking backward compatibility
- Demonstrated that significant protocol changes could be deployed as soft forks