Segregated Witness activated at block 481,824, mined at 01:57 UTC on 24 August 2017. It is usually filed under "the block size compromise", the least interesting thing about it. What it did was take signature data out of the structure a transaction's identifier is computed from, then charge for it at a different rate. Both halves still shape what a block holds today.
The problem it was built to fix
A transaction's txid is a hash of the transaction, and before SegWit the data hashed
included the signatures. Signatures are not unique: an ECDSA signature can be rewritten into
a second one equally valid over the same message, and a scriptSig can be padded in ways the
interpreter accepts. So anyone relaying an unconfirmed transaction could alter it and
rebroadcast it, producing a transaction that pays the same amounts to the same addresses
under a different txid. That is transaction malleability. It steals nothing, since the
outputs cannot change without a valid signature over them. What it breaks is everything that
refers to a transaction before it confirms.
The serious damage is one level up. A protocol that pre-signs a second transaction spending
the output of an unconfirmed first one has to name the first by txid. Change the txid and
the second spends an output that does not exist, and cannot be re-signed if the
counterparty has gone quiet. That is the shape of a Lightning channel: a funding transaction,
plus a commitment transaction signed in advance so either side can get their money back. BIP
141 puts the fix in exactly those terms: it "allows creation of unconfirmed transaction
dependency chains without counterparty risk, an important feature for offchain protocols such
as the Lightning Network."
The most-repeated story about it is also the least accurate. Mt. Gox blamed malleability attacks for draining its accounts when it filed for bankruptcy in February 2014, but Decker and Wattenhofer measured the preceding year of traffic and found "no widespread use of malleability attacks before the closure of MtGox."
Moving the witness out of the identifier
BIP 141 defines "a new structure called a witness that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but not required to determine transaction effects." What a transaction does is decided by the outputs it consumes and creates; the signatures only prove you were allowed.
So a transaction gets two identifiers. The txid is unchanged: the double SHA256 of
[nVersion][txins][txouts][nLockTime]. A new wtxid is the double SHA256 of
[nVersion][marker][flag][txins][txouts][witness][nLockTime]. The txid commits to what the
transaction does and not to how it was authorised, so "changes to how the transaction was
signed are no longer relevant to transaction identification."
The witness is not thereby unchecked: wtxid values are hashed into a witness root committed
in an OP_RETURN output of the coinbase transaction, and
BIP 143 gave witness spends
a signature digest that also covers the amount being spent. But the fix is per transaction,
not per network: "segwit transactions only avoid malleability if all their inputs are segwit
spends."
Block weight, exactly as BIP 141 defines it
Before SegWit, "blocks are currently limited to 1,000,000 bytes (1MB) total size." BIP 141 replaces that with a limit in a different unit, built from two measurements of the same block. Base size is "the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node." Total size is the block size "including base data and witness data." Then:
Block weight is defined as Base size * 3 + Total size. [...] The new rule is block weight ≤ 4,000,000.
Read it slowly; secondary coverage garbles this constantly. A byte outside the witness appears in Base size and again in Total size, so it is counted 3 + 1 times: a non-witness byte costs four weight units and a witness byte costs one. Signature data is charged a quarter of the rate charged to everything else. A transaction's weight divided by four, rounded up, is its virtual size: the sats-per-vbyte unit.
Why the capacity is not a number
Write the rule as weight = 4 * base + witness ≤ 4,000,000 and a consequence falls out: base size can never exceed 1,000,000 bytes. The block a non-upgraded node sees, with the witness stripped, is still under a megabyte, and still satisfies the rule it enforces.
The second consequence is that there is no fixed capacity in bytes. Four megabytes would need a block made almost entirely of witness data, which no real block is. Bitcoin Core's 2016 write-up estimated "an effective limit closer to 1.6 to 2 MB", and mainnet-observer's daily averages give December 2017 at 1.05 MB and 3.96 million weight, May 2023 at 1.70 MB and 3.98 million, and the thirty days to 19 August 2026 at 1.62 MB and 3.93 million. Same cap, three byte counts, because the transaction mix changed underneath it. Miners fill four million weight units and sort by fee per weight unit, so capacity in bytes is an output of what people are doing, not an input.
How a soft fork did this
A witness program is a scriptPubKey consisting of a version byte push followed by a push of
2 to 40 bytes, and a spend of one carries an empty scriptSig. Run that through a node from
2016: it sees 0 <20-byte-hash>, evaluates it as an ordinary script, finds a non-empty value
left on the stack, and calls it success. It has accepted a spend with no signature in it. BIP
141 says so: non-upgraded nodes "will not see nor validate the witness data and will consider
all witness programs as anyone-can-spend scripts."
That is what makes a soft fork possible, and it has a price. Backwards compatibility means the old node is not validating those spends; it accepts them because it cannot see the rule they satisfy. What protects the coins is the upgraded nodes and the hashpower enforcing BIP 141, not the old node's own check.
The addresses, and why they took years
Under witness version 0, a 20-byte program is pay-to-witness-public-key-hash (P2WPKH): the
program is the HASH160 of a public key, and the witness holds a signature and that key. A
32-byte program is pay-to-witness-script-hash (P2WSH), the same idea for a script: the program
is the SHA256 of a witnessScript revealed at spend time, longer than P2SH's 20 bytes
because it "improves security against possible collision attacks". Either can be nested
inside a P2SH output, which is how wallets shipped SegWit before bech32 was widely supported,
at 24 extra non-witness bytes each spend.
Native witness outputs needed a new address format, and that is
BIP 173: bech32, "a
checksummed base32 format", with the human-readable part bc on mainnet. Base58 "needs a lot
of space in QR codes" and its "double SHA256 checksum is slow and has no error-detection
guarantees"; bech32 uses a BCH code that "guarantees detection of any error affecting at most
4 characters".
Adoption then took years, for a reason unrelated to cryptography: a new receiving address is useless until the software sending to it can parse the format, and the sending side is every exchange and wallet. Counting transactions spending at least one witness input, mainnet-observer's daily series puts the share near 3 percent in September 2017 and 15 percent in February 2018; it first crossed half in October 2019, slipped back under for most of 2020, and settled above 80 percent only from November 2021. Over the thirty days to 19 August 2026 it was 97.5 percent, which now includes Taproot, since a BIP 341 output is witness version 1.
What it does not do
It did not raise the block size to four megabytes, as the measurements above show. It did not make fees permanently cheap, because changing the price of one kind of byte relative to another is not the same as adding room. It changed nothing about ownership, issuance or the supply schedule. It does not fix malleability for a transaction that still has one non-witness input. And it did not make a non-upgraded node better informed: such a node now validates strictly less than it did before.
A discount is a price, and prices have consequences
The discount is about what a byte costs a node years from now: signature data can be discarded once checked, while an output sits in the UTXO set every node keeps. So SegWit makes "signature data, which does not impact the UTXO set size, cost 75% less than data that does impact the UTXO set size", an incentive toward transaction shapes that leave less permanent residue. BIP 141 named it in advance: the "size of witness could be ignored / discounted when calculating the block size".
What nobody anticipated is that "witness" would stop meaning "signatures". Taproot's script path removed the old ceiling on script size, and once arbitrary bytes could sit inside a witness the discount applied to them too, which is how inscriptions came to store images at a quarter of the going rate, and how the fee market behaved in May 2023.
Nobody chose to subsidise images. A price was set on a resource for good reason, and six years later people optimised against it for a purpose its authors had not imagined. The four million weight unit limit is less a compromise about block size than a claim about which bytes cost a node something, and every argument about block space since has been about whether that claim still holds.