What Is SegWit? Bitcoin's Segregated Witness Upgrade

SegWit (Segregated Witness) is a 2017 Bitcoin protocol upgrade that restructured how transaction data is stored by separating ("segregating") the signature data — called the "witness" — from the rest of the transaction, which fixed a long-standing bug called transaction malleability and effectively increased how many transactions fit in each block.

The problem SegWit solved

Before SegWit, every part of a Bitcoin transaction — including the digital signatures unlocking its inputs — was hashed together to produce the transaction ID (txid). This created a subtle issue: it was possible, without invalidating the signature, for a third party (or even the sender's own wallet software in rare cases) to slightly alter the signature's encoding in a way that changed the transaction's ID without changing its economic effect. This is called transaction malleability.

This mattered because software that tracked transactions by their ID could get confused if the ID changed unexpectedly, even though the transaction still did exactly what it was supposed to. It was a particular headache for systems built on top of Bitcoin that needed to reference unconfirmed transactions by ID — including early designs for payment channels and what would become the Lightning Network, part of the broader layer-2 landscape covered in /blog/layer2-guide.

How SegWit fixed it

SegWit's core change was to move the witness data (signatures and related unlocking scripts) outside of the data used to calculate the transaction ID. Once the signature data no longer affects the txid, malleability of that type becomes structurally impossible — altering the signature encoding can't change the ID anymore, because the ID calculation doesn't include it.

This restructuring also changed how transaction size is measured. SegWit introduced the concept of "weight units" and "virtual bytes" (vBytes), where witness data is discounted relative to non-witness data when calculating a transaction's effective size for fee and block-size purposes. Since witness data (signatures) often makes up a significant portion of a transaction's total data, discounting it effectively let more transactions fit within the same block weight limit — a soft increase in throughput without literally raising a hard byte-size cap.

SegWit and fees

Because SegWit transactions are measured in discounted vBytes rather than raw bytes, they're generally cheaper to send than equivalent legacy transactions, since their effective size (and therefore their fee at a given sat/vByte rate) is lower. This is one of the most direct, everyday benefits of SegWit for regular users and is a key reason our fee-reduction guide (/blog/how-to-reduce-bitcoin-transaction-fees) recommends switching to SegWit-format addresses if you haven't already. For the underlying fee mechanics, see /blog/how-bitcoin-transaction-fees-work.

SegWit address formats

SegWit introduced new address formats, most commonly recognized by their prefixes:

Address type	Prefix	Description
Legacy (pre-SegWit)	Starts with "1"	Original P2PKH format, largest transaction size
Nested SegWit	Starts with "3"	SegWit wrapped inside a legacy-compatible script, moderate savings
Native SegWit (Bech32)	Starts with "bc1q"	Full SegWit format, most space-efficient of the three

Nested SegWit was designed as a transitional format, letting SegWit transactions be sent and received by wallets and services that hadn't yet upgraded to understand native SegWit addresses directly. Native SegWit offers the best fee savings and is now widely supported.

Why SegWit was controversial at the time

SegWit's activation in 2017 came after a lengthy, sometimes contentious debate within the Bitcoin community about how to scale the network — some advocated for simply raising the block size limit directly instead of adjusting how data was measured and discounted. This disagreement eventually led to a network split, producing Bitcoin Cash as a separate chain that pursued larger blocks directly rather than adopting SegWit's approach. This period is a useful case study in how consensus changes work (or fail to reach agreement) in decentralized, permissionless networks — a dynamic also relevant when comparing different base-layer design philosophies, as in /blog/layer1-blockchains-compared.

SegWit as a foundation for later upgrades

Beyond its immediate benefits, SegWit's redesigned transaction format laid essential groundwork for later improvements. The Taproot upgrade, covered in /blog/taproot-upgrade-explained, builds directly on SegWit's version-tagged output structure to introduce Schnorr signatures and more flexible, private scripting. Without SegWit's restructuring first, Taproot's design would have been significantly more difficult to implement cleanly.

Should you care about SegWit today?

For most users, the practical takeaway is simple: if your wallet or exchange still generates legacy "1" addresses for you, moving to a native SegWit ("bc1q") or Taproot ("bc1p") wallet will lower your transaction fees with no meaningful downside, since SegWit has been supported by essentially the entire Bitcoin ecosystem — exchanges, wallets, and mining pools — for years. If you're managing wallet security more broadly, our /blog/defi-wallet-security guide and the /wallet resources cover good practices alongside address format choices.

Bottom line

SegWit solved transaction malleability by separating signature data from the transaction ID calculation, and as a side effect, it made transactions cheaper by discounting witness data in fee calculations. It remains one of the most consequential Bitcoin protocol upgrades, both for its direct benefits and as the technical foundation that later enabled Taproot.