SegWit

The change was structural, not cosmetic. Signatures went into a witness section that old nodes never download, which let a capacity increase ship as a soft fork, and witness bytes cost one weight unit each instead of four. Spending from a bc1q address therefore costs roughly half what a legacy input costs.

How it works

Segregated Witness splits a transaction into two parts and hashes them separately.

The base part holds the version, the inputs, the outputs and the locktime. The witness part holds, for each input, the stack of items that authorizes it, typically a signature and a public key. The transaction identifier is computed over the base part alone, so nothing in the witness can change it. A second identifier, the wtxid, covers both, and the merkle root of all wtxids in a block is committed inside the coinbase transaction so the witness data cannot be tampered with either.

Capacity follows from a change in accounting rather than a change in the limit. Every byte outside the witness costs four weight units, every byte inside costs one, and a block may hold 4,000,000 weight units. Non-witness data therefore still cannot exceed 1,000,000 bytes, exactly as before, while signatures ride along in the spare budget. A pre-2017 node measuring the old way sees a legal block and raises no objection, which is precisely why the upgrade needed no hard fork.

BIP-143 rewrote how a witness input is signed, and the practical gain is larger than it sounds. The old signature hash algorithm rehashed parts of the transaction once per input, so signing an input-heavy transaction grew quadratically. The new one reuses precomputed hashes and, critically, commits to the amount being spent. Before that, a hardware wallet could be lied to about how much an input was worth and made to authorize a huge fee.

SegWit also numbered its output types. Witness version 0 covers P2WPKH and P2WSH; witness version 1 was left empty and later filled by Taproot. New output types can now be added without a new address format argument each time.

Why this matters when you buy bitcoin

Three things in your own use of bitcoin trace directly back to this upgrade.

The first is what you pay to move coins. A native SegWit input is around 68 vbytes against roughly 148 for a legacy one, so a wallet spending three inputs at a 20 sat/vB fee rate saves several thousand satoshis on a single transaction. That saving lands when you spend, not when you receive, so it is the address type your own wallet uses that matters, not the one your exchange withdraws from.

The second is what your hardware wallet can safely tell you. Because BIP-143 commits the input amount, the fee shown on a Trezor or Ledger screen is derived from data the device can verify rather than data the connected computer asserts. That closed a real attack, and it is why signing a legacy input still requires the device to be handed the entire previous transaction so it can check the amount itself.

The third is Lightning, and therefore any exchange built on it. Strike moves value over Lightning by default, and Lightning channels are funded into SegWit outputs because the protocol cannot function without a stable txid. No SegWit, no channels, no instant settlement product on top of them.

The malleability bug that had to die first

Transaction malleability sounds like an edge case and was the single largest obstacle to building anything on top of bitcoin.

An ECDSA signature has more than one valid encoding. Before SegWit, a third party watching the mempool could take an unconfirmed transaction, re-encode a signature without invalidating it, and rebroadcast. The coins still moved to the same place for the same amount. Only the transaction identifier changed, and any software that had recorded the original identifier now believed the payment had vanished. Mt. Gox publicly blamed malleability for halting withdrawals in February 2014, a claim other developers disputed at the time, but the underlying flaw was real.

Payment channels made it fatal rather than annoying. A channel works by holding a signed refund transaction that spends a funding output identified by its txid, before that funding transaction is even broadcast. Change the txid and the refund becomes unspendable, leaving one party able to hold the other's money hostage. The 2015 Lightning Network paper by Joseph Poon and Thaddeus Dryja named a malleability fix as a prerequisite in its own text.

SegWit removed the problem at the root by taking signatures out of the identifier's preimage. Any input spending a witness output has a txid that no third party can alter, and channel protocols could finally be built as designed.

SegWit vs witness data

SegWit is the upgrade; witness data is the structure it created. One is an event with a date, August 24, 2017, and a specification, BIP-141. The other is a field that exists in most transactions on the network today, carrying signatures and scripts, and that has its own serialization and its own discounted weight. Saying a transaction "uses SegWit" is shorthand for saying it spends inputs whose authorization lives in that field.

SegWit vs Taproot

Two soft forks, four years apart, both about witnesses. SegWit created the witness structure and defined version 0 output types, the ones whose addresses start bc1q. Taproot filled version 1, added Schnorr signatures and changed how scripts inside a witness are evaluated, producing addresses starting bc1p. Taproot could only be deployed as cheaply as it was because SegWit had already built the versioning scheme, which is why the two are best read as one design carried out in stages.