SegWit explained: Segregated Witness and its BIPs

SegWit (Segregated Witness) is the soft fork that moved signatures and other unlocking data out of the part of a transaction its ID is computed from, into a separate "witness" section. That fixed third-party transaction malleability, replaced the 1 MB block size limit with a limit of 4 million weight units, and added versioned outputs that later made Taproot possible. It is defined mainly in BIP 141 and activated at block 481,824 on 24 August 2017.

Updated 2026-10-20 · 9 min read

What is SegWit?

Every transaction input carries data that proves the spender is allowed to spend: signatures, public keys and sometimes a script. That data is called the witness. Before SegWit it lived inside each input's scriptSig, so it was part of the bytes hashed into the transaction ID (txid). SegWit moves it into a separate structure that blocks commit to in a different place and that the txid does not cover.

BIP 141, written by Eric Lombrozo, Johnson Lau and Pieter Wuille, defines the consensus rules. It describes the witness as data "required to check transaction validity but not required to determine transaction effects." Who paid whom and how much stays in the main transaction; the proof that the payment was authorized moves out.

SegWit is a soft fork: it only tightens the rules, so nodes that never upgraded still accept the blocks. To an old node a SegWit output looks like a script anyone could spend, and it receives blocks without the witness data. Upgraded nodes enforce the full rules. BIP 141 notes that wallets "should always be wary of anyone-can-spend scripts", one reason node operators were encouraged to upgrade.

The problem SegWit solved: transaction malleability

Transaction malleability means someone other than the signer can change a transaction's bytes, and so its txid, without making it invalid. ECDSA signatures are malleable by nature: as BIP 340 puts it, a third party "can alter an existing valid signature for a given public key and message into another signature that is valid for the same key and message." There were other vectors too, such as the unused "dummy" element that OP_CHECKMULTISIG consumes.

A changing txid matters because a transaction that spends an unconfirmed output refers to it by txid. If the parent's txid changes before it confirms, every pre-signed child becomes invalid. That breaks any protocol that builds chains of pre-signed transactions, such as payment channels. BIP 141 says SegWit "allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the Lightning Network."

Earlier work patched individual vectors: BIP 62 (Pieter Wuille) proposed canonical-encoding rules to rule out each known vector, and BIP 66 made strict DER signature encoding a consensus rule in 2015. SegWit took a different route. Since signatures are no longer hashed into the txid at all, changing them cannot change the txid, for any script type "as long as all inputs are signed". BIP 147 by Johnson Lau closed the dummy-element gap in the same deployment by requiring that element to be empty (the NULLDUMMY rule), which keeps the witness txid stable too.

What moved to the witness

Two IDs: txid and wtxid

After SegWit every transaction has two identifiers:

• txid: double SHA-256 of [nVersion][txins][txouts][nLockTime]. The definition did not change, so old software computes the same IDs.
• wtxid: double SHA-256 of [nVersion][marker][flag][txins][txouts][witness][nLockTime], which includes the witness. The marker is 0x00 and the flag 0x01.

Blocks commit to every wtxid through a second Merkle tree, whose root goes into an OP_RETURN output of the coinbase transaction starting with 0x6a24aa21a9ed. Putting the commitment in the coinbase, rather than the block header, is what kept SegWit a soft fork.

Witness programs and version numbers

A SegWit output script is a version number (OP_0 to OP_16) followed by a 2 to 40 byte "witness program". BIP 141 gives meaning to version 0 with two program sizes:

Versions 1 to 16 were left undefined and spendable by anyone under the old rules, so a later soft fork could give them meaning without disturbing old nodes. Version 1 became Taproot in 2021 (BIP 341). See BIP 141 vs BIP 341 for how the two compare.

Block weight, weight units and vbytes

SegWit replaced the 1,000,000-byte block size limit with a limit on block weight:

• Block weight = base size × 3 + total size, where base size excludes witness data and total size includes it.
• The rule: block weight must be at most 4,000,000 weight units (WU).

Put another way, each non-witness byte counts as 4 WU and each witness byte as 1 WU. An old node only sees the base size, so to it every valid block is still at most 1 MB. BIP 141 explains why it chose one combined limit instead of two separate ones (1 MB of base data plus 3 MB of witness): two limits would make fee estimation and block building "nearly impossible".

For single transactions BIP 141 defines virtual size: weight divided by 4, rounded up, measured in vbytes (vB). Fee rates are quoted in satoshis per vbyte, so a witness byte costs a quarter of what a non-witness byte costs. Typical sizes for a payment with one input and two outputs:

Exact numbers depend on signature length and output types. The transaction size calculator works them out for any mix of inputs and outputs.

The SegWit BIPs

SegWit is a group of BIPs. BIPs 141, 143 and 147 were the consensus changes, deployed together; the others cover networking, mining, addresses and wallets.

BIP 143: a faster, safer signature hash

BIP 143 changed what a signature commits to, for SegWit version 0 only. It fixed two weaknesses of the original algorithm:

1. Quadratic hashing. Every signature check used to rehash most of the transaction, so the work grew with the square of the transaction size. BIP 143 notes that a 1 MB block normally took about 2 seconds to verify in 2015, but a 1 MB transaction with 5,569 signature operations could take 25 seconds. The new algorithm hashes the prevouts, sequences and outputs once and reuses them, making the work linear.
2. Unsigned input amounts. The old signature did not cover the value being spent, so an offline signer such as a hardware wallet could not be sure of the fee without the full previous transactions. BIP 143 signs the amount, so if a wallet is fed a wrong value the signature is simply invalid.

Native SegWit vs nested SegWit

When SegWit launched, many wallets and services could not yet pay to the new bc1 addresses. Nested SegWit wraps a SegWit program inside an ordinary P2SH output, so it gets a "3" address that every wallet could already pay. BIP 141 calls it "fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0", at the cost of a 23-byte larger scriptSig that is not discounted.

Bech32 addresses are all one case, at most 90 characters long, and their checksum is guaranteed to detect any error affecting up to 4 characters. More detail is in BIP 49 vs BIP 84, the derivation paths guide and the address types guide. The address checker tells you which type an address is.

How SegWit activated

SegWit was deployed with BIP 9 version bits, named "segwit" on bit 1. Its activation was the most contested upgrade so far, and accounts of 2017 still differ on which pressures mattered most. The main events, from the BIP texts:

Signaling had stayed well below 95% for months. Some users and businesses backed BIP 148, some miners and companies backed BIP 91, and some parties tied SegWit to a later block size increase. Separately, on 1 August 2017 a group that preferred larger blocks without SegWit split off through a hard fork, creating Bitcoin Cash. The lessons of 2017 shaped later activation proposals such as BIP 8 and the Speedy Trial method used for Taproot; the soft forks guide and BIP 8 vs BIP 9 cover them.

What SegWit made possible

• Lightning and other payment channels, which rely on pre-signed transactions whose txids cannot change. See the BIPs behind Lightning.
• More capacity without a hard fork, through the weight limit.
• Safer offline signing, since BIP 143 signatures commit to the amounts being spent.
• Script upgrades by version number, which is how Taproot arrived as witness version 1.
• Cheaper, easier addresses: bech32 is case-insensitive and fits QR codes better than Base58.

The full list of SegWit-related BIPs is on the SegWit topic page.