Segregated Witness

Segregated Witness, or SegWit, is a Bitcoin upgrade that activated at block 481,824 on 24 August 2017. It moved each transaction's signatures and unlocking data into a separate witness field. That change affects how transactions get their IDs, how their size is counted, and how blocks fill up. This page covers the technical changes. For the reasons in plain words, read the SegWit word page or the beginners' SegWit guide.

The upgrade is defined by three BIPs. BIP 141 sets the consensus rules. BIP 143 defines the signature hash for the new scripts. BIP 144 covers how peers exchange witness data.

Why was SegWit needed?

The main reason was transaction malleability. Before SegWit, a transaction's TXID was a hash of its full contents, signatures included. A signature can be changed in a way that stays valid, and that changes the TXID. Any unconfirmed transaction that spends one of its outputs points at the old TXID, so it becomes invalid. A miner could use this to cancel a chain of unconfirmed transactions.

SegWit fixes this by leaving the witness out of the TXID. The TXID then covers only the base data, and a signature can no longer change it. Children of an unconfirmed transaction can rely on its TXID.

The same change made room for a larger block, which is why SegWit arrived as one package of changes.

How did SegWit activate?

SegWit used version bits signalling, the same mechanism the later Taproot upgrade used. Miners signalled in the version field of their blocks, and signalling could run from 15 November 2016 to a deadline of 15 November 2017. A retarget period needed 95% of its blocks, or 1,916 of 2,016, to signal before the rule could lock in.

Every block in the period that ended at block 479,807 signalled support. The rule therefore locked in at block 479,808, on 9 August 2017. It became active 2,016 blocks later, at block 481,824.

What changed in the transaction format?

A legacy transaction holds each input's signatures in its scriptSig. A SegWit transaction moves them into a witness section at the end of the transaction. It also adds two bytes after the version: a marker 00 and a flag 01. Software written before SegWit reads the marker as a transaction with zero inputs, so it will not accept the transaction as normal.

The witness section is a list of stacks, one per input. Each stack is a count followed by its items, and each item is a length and its bytes. Legacy inputs have no witness stack, so the section is empty for them.

How is transaction size counted?

SegWit replaced the old size limit with a weight limit. Base data counts four times, and witness data counts once. This gives the signature data a discount.

A block may carry up to 4,000,000 weight units. Virtual bytes, or vbytes, are the weight divided by four, rounded up.

The old limit was 1,000,000 bytes of block data. A block now reaches close to 4 MB only when most of its bytes are witness data, since those count once. Fee rates are quoted per vbyte, so witness data costs less per byte than base data does.

Signature operations have a cost limit too. Legacy signature operations count four times, and a block may carry at most 80,000 units of signature cost.

What are the new locking scripts?

SegWit added two locking scripts, and both use the witness for their unlocking data.

• P2WPKH locks an output to a public key hash. Its scriptPubKey is OP_0 followed by a 20-byte push, 22 bytes in total. The witness holds a signature and the public key. See P2WPKH.
• P2WSH locks an output to a script hash. Its scriptPubKey is OP_0 followed by a 32-byte push, 34 bytes in total. The witness holds the script's inputs and the script itself. See P2WSH.

These scripts do not use the Script language for the lock. They use a fixed structure, and their unlocking rules are built in. Their addresses use bech32, defined in BIP 173. Version 0 addresses start with bc1q.

BIP 143 defines the signature hash for these scripts. It commits to the amount of the input being signed, and it hashes the shared parts of the transaction once instead of once per input. Older signing code could take a long time to hash a large transaction, so this was a real gain.

What is a witness commitment?

The witness is outside the TXID, so something else has to commit to it. Each transaction also has a wTXID, a hash of its full serialization including the witness. A legacy transaction has no witness, so its wTXID equals its TXID. The coinbase transaction's wTXID is treated as all zeros.

Miners put the merkle root of all the wTXIDs in the block as a witness commitment. It sits in an extra output of the coinbase transaction. That output is an OP_RETURN with a 36-byte push, starting with the bytes aa21a9ed and followed by the 32-byte commitment.

Because the commitment is in the block, nobody can change the witness data of a confirmed transaction without breaking the block. The coinbase is a convenient place for it, because the merkle root in the block header already commits to the coinbase transaction.

Two identifiers can confuse you. The TXID excludes the witness, and it is the ID most tools show. The wTXID includes it. The getrawtransaction command reports the wTXID in its hash field.

What changed on the network?

Nodes request transactions and blocks with getdata, and each request names a type. A node that wants the signatures asks with the witness type, so the peer sends the witness too. Without it, the peer sends the transaction without its witness.

Type	Value	Meaning
MSG_TX	01000000	transaction, no witness
MSG_BLOCK	02000000	block, no witness
MSG_WITNESS_TX	01000040	transaction with witness
MSG_WITNESS_BLOCK	02000040	block with witness

The witness types add 0x40000000 to the old type, which is bit 30. A node that supports witness data also advertises it in its service bits, as described on the networking page.

Where can you see it?

The SegWit activation block is 481,824. Its hash is 0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893, and its block time is 24 August 2017, 01:57 UTC. Blocks from that height onward can carry transactions with witness data.

The next upgrade, Taproot, uses the witness format this page describes.