Protocol & Mining
SegWit, and what BIP 141 actually changed
Protocol referenceSource: BIP 141, Segregated WitnessThe weight constants and the witness discount are quoted from BIP 141.
The problem it addressed
A transaction's identifier is a hash of its serialised bytes. That sounds innocuous and it is the source of a long-standing annoyance: because the signature is part of the bytes being hashed, anyone who can alter the signature without invalidating it can change the transaction's identifier. The signature scheme used before SegWit permitted exactly that, in a way that did not change the transaction's meaning. The result was transaction malleability: a third party could take a valid transaction, produce a different but equally valid version of it, and thereby change the identifier that any dependent transaction had committed to.
Malleability mattered for more than tidiness. A chain of transactions that spends an unconfirmed parent has to name the parent's identifier, and if that identifier can be changed by someone else, the child can be invalidated through no fault of its author. It also made layered protocols difficult, because a protocol that builds on a transaction cannot safely do so while the transaction's identity is mutable. Fixing malleability was a prerequisite for the second-layer designs that followed.
The block size limit was the other half of the problem, and the more public one. The original rule capped a block at one million bytes, and as usage grew the cap became a binding constraint on how many transactions could be confirmed. Raising it directly was contentious, because a larger block is more expensive to propagate and to validate, and the disagreement about how far to raise it and how quickly became a years-long argument.
What BIP 141 did
Segregated Witness separates the witness — the signatures and other data that satisfy a spending condition — from the rest of the transaction. The witness is still transmitted and still validated, but it is no longer part of the bytes from which the transaction identifier is computed. Malleability disappears as a consequence, because altering a signature no longer changes the identifier. A new identifier, the witness transaction identifier, is defined for cases where the witness data does need to be committed to.
The block limit was replaced rather than raised. BIP 141 defines a block's weight as the size of its non-witness data multiplied by four, plus the size of its witness data multiplied by one, and caps a block at 4,000,000 weight units. A block made entirely of non-witness data therefore still fits in one million bytes, because four times one million is four million. A block that carries witness data can be physically larger than a megabyte, because the witness bytes count at a quarter of the rate. The one-megabyte figure did not vanish; it became the base-data component of a larger budget.
The discount is the mechanism by which SegWit increased capacity without a hard fork to the block size. Witness bytes are cheaper in weight terms, so a transaction that moves its signature data into the witness pays less for the same economic effect. That is why a native SegWit spend is cheaper in fee terms than the equivalent legacy spend, and why the address types page treats the witness discount as a reason to prefer the newer forms.
What followed
The immediate consequence was capacity. Because witness data is discounted, the same one-megabyte base budget can carry more transactions than before, and the effective throughput of the network rose without any change to the base block limit. The size of the increase depends on how much of the traffic uses witness outputs, which is why it grew gradually as wallets adopted the new formats rather than arriving all at once.
The structural consequence was larger. Removing malleability made it possible to build protocols on top of Bitcoin that commit to a transaction before it is confirmed. The most significant of those is the Lightning Network, whose channels are opened and closed by transactions that reference each other and which could not have been built safely while a transaction's identifier could be changed by a third party. SegWit is therefore best understood not as a block size compromise but as the change that made a class of layered protocols possible.
The third consequence was a new address format. Witness outputs are encoded in bech32, which is more robust against transcription errors than the older Base58Check encoding, and which was designed to be efficient in QR codes. The block size and weight page works through the weight arithmetic in detail, and the Taproot page covers the upgrade that built on the witness structure.
Sources
- BIP 141, Segregated Witness (Consensus layer) — the witness structure, the weight definition and the 4,000,000 weight-unit limit.
- BIP 143, Transaction Signature Verification for Version 0 Witness Program — the signature hashing algorithm that replaced the malleable one.
- Bitcoin Developer Guide, Transactions — witness programs and their address encodings.
Related reading
- Protocol, Transactions & MiningThe supply schedule, transaction mechanics and mining economics behind the price.
- Proof of WorkThe hash puzzle, the target and nonce, and why accumulated work secures the chain.
- Difficulty AdjustmentThe 2,016-block retarget, its caps, and the ten-minute target it defends.
- HashrateWhat hashrate measures, why it is estimated, and how it differs from difficulty.
- Mining PoolsPooled hash rate, share accounting, payout schemes and centralisation.
- Miner RevenueThe block subsidy plus fees, and how the mix changes across subsidy epochs.