Bitcoin transactions often feel unpredictable — confusing address formats, arcane terms like block weight. But one upgrade sits behind many improvements users now take for granted: Segregated Witness (SegWit). Deployed as a soft fork at block height 481,824 on August 24, 2017, SegWit changed how transaction data is structured without breaking older nodes.
Ending Transaction Malleability
Before SegWit, signature data was part of the transaction hash used to generate the transaction ID (txid). Attackers could alter signature encoding and produce a different txid while keeping payment details intact. SegWit moved witness data — signatures and scripts — out of the traditional txid calculation, making transaction identifiers reliable. BIP-147 added the NULLDUMMY rule to fix a remaining malleability issue with multisig transactions.
Block Weight and Space Efficiency
SegWit replaced the 1 MB block size limit with a maximum block weight of 4,000,000 weight units. BIP-141 defines weight as base size × 3 + total size. Each base byte contributes four weight units, each witness byte only one — effectively a 75% discount on signature data. This does not mean blocks can simply be 4 MB; actual size depends on the mix of legacy and SegWit transactions. Fees are calculated using virtual size (vsize) = transaction weight ÷ 4. Native SegWit spends typically save about 30% in fees compared to similar legacy transactions, with multi-input or multisig spends saving even more.
Safe Foundation for Lightning Network
Payment channels rely on transactions referencing earlier txids. Transaction malleability could change a channel's funding txid and invalidate dependent transactions. SegWit fixed that, creating a secure base for the Lightning Network and other Layer 2 systems. It also introduced a witness version byte (version 0 for P2WPKH/P2WSH, later version 1 used by Taproot), allowing future soft forks to add new script rules without a separate format.
Key BIPs and Address Formats
SegWit is defined by several Bitcoin Improvement Proposals: BIP-141 (consensus rules), BIP-143 (signature digest changes improving hardware wallet compatibility), BIP-144 (peer-to-peer relay), BIP-147 (NULLDUMMY rule), and BIP-173 (Bech32 address encoding). Native SegWit addresses start with bc1 and are more efficient than legacy addresses starting with 1 or 3.
SegWit does not eliminate network congestion — fees can still spike during high demand — but it uses limited block space more effectively. For everyday users, a wallet supporting native SegWit addresses generally means cheaper and faster bitcoin transactions.