Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Protocol & Mining

SegWit, and what BIP 141 actually changed

Segregated Witness moved the signature data out of the part of a transaction that its identifier is computed from, and replaced the block size limit with a weight limit that counts witness bytes at a discount. Both changes were structural, and both had consequences well beyond the block size debate that prompted them.

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