Segregated Witness

• BIP 141: Segregated Witness (Consensus layer)
• BIP 143: Transaction Signature Verification for Version 0 Witness Program
• BIP 144: Segregated Witness (Peer Services)

Segregated Witness (SegWit) was a major upgrade to the Bitcoin software activated in 2017.

The main changes were a new transaction structure, a block size increase, and the addition of a new address format.

This page lists the technical changes introduced in the Segregated Witness upgrade. For an introduction on why and how the upgrade took place, check out the beginners guide to SegWit.

Motivation

Why was Segregated Witness introduced?

The primary reason for the Segregated Witness upgrade was to fix transaction malleability.

Before Segregated Witness, the TXIDs for legacy transactions were created from the entire transaction data, including the signatures.

However, it's possible to adjust the signatures inside a transaction and for them to remain valid, and this would have a knock-on effect to the TXID. This meant that it was possible for someone to change the TXID for your transaction after you sent it in to the network.

The problem with this is that any transactions that depend on this TXID (i.e. transactions that spend one of the outputs while it was still in the memory pool) would become invalid. In other words, a miner could "cancel" the descendants of memory pool transactions and prevent them from getting mined in to a block.

Therefore, the primary change in the Segregated Witness upgrade was a modification to the transaction data structure so that the signatures were no longer included as part of the TXID calculation, making TXIDs dependable and allowing you to confidently spend the outputs of transactions whilst they are still in the memory pool.

This new transaction data allowed for a block size increase at the same time, which is why Segregated Witness was introduced as suite of changes in one major upgrade to the software.

Technical Changes

What were the changes to the Bitcoin?

The following is a list of all the changes that took place to Bitcoin with the Segregated Witness upgrade.

I'll start with the most significant changes first (the ones you're most likely to run in to as a developer), and work down to the minor changes.

1. Transaction Structure

The primary change was the addition of a new segwit transaction structure.

These new segwit transactions include a new witness section that holds the unlocking code (i.e. signatures) for the new locking scripts introduced in the upgrade.

So whereas legacy transactions would use the ScriptSig field for unlocking inputs, segwit transactions now use the new witness section instead.

2. Transaction Size Calculation

With the addition of the new witness field, transactions were also given a new size calculation called weight.

Instead of measuring the size of a transaction purely on the number of bytes, different parts of the transaction data were given specific multipliers so that some parts of a transaction would "weigh less" than others:

As a result, the unlocking code in a segwit transaction weighs less than the unlocking code in a legacy transaction, effectively giving a size discount (and reduced fee costs) to anyone using new segwit transactions.

3. Block Size Increase

Using the new weight calculation for transactions, the block size limit was changed from 1,000,000 bytes to 4,000,0000 weight units.

This results in a block size increase that is up to 4 times bigger than the old block size limit.

Seeing as transaction data always contains some legacy data along with the new segwit data, the effective block size increase works out to be around 1,700,000 to 2,000,000 bytes on average (depending on the composition of transactions included in the block).

4. Locking Scripts

Two new locking script patterns were introduced to take advantage of the new witness field for unlocking certain types of outputs:

1. P2WPKH
2. P2WSH

These are functionally the same as the legacy P2PKH and P2SH locking scripts.

The main difference is that P2WPKH and P2WSH are unlocked using the witness area of a transaction instead of the ScriptSig.

The new P2WPKH and P2WSH locking scripts do not use the traditional Script language for locking and unlocking. They use a fixed structure of bytes instead, and have their own hard-coded method for execution. But nonetheless, they are still functionally the same as P2PKH and P2SH.

5. Address Format

The new P2WPKH and P2WSH locking scripts use a new Bech32 address format.

These Bech32 addresses allow for better error-detection and are easier to transcribe.

So whereas legacy P2PKH and P2SH locking scripts continue to use Base58 addresses, the new P2WPKH and P2WSH locking scripts use Bech32 addresses instead.

6. Signature Algorithm

The new P2WPKH and P2WSH locking scripts also make use of a new signature algorithm.

This new "segwit signing algorithm" is designed to be more efficient than the legacy signing algorithm.

So now the process for creating signatures to unlock P2WPKH and P2WSH locking scripts is different to the process for creating signatures for legacy locking scripts (e.g. P2PKH and P2SH).

Both the legacy and new segwit signing algorithm still use ECDSA. It's just that now the method for preparing the transaction data for signing is different when you want to unlock P2WPKH and P2WSH locking scripts.

7. wTXID Commitment

Due to the fact that new segwit transactions contain data that is no longer part of the TXID, this new witness data needs to be committed to the block via a wTXID commitment.

So in addition to the TXID (which does not include the new fields in a segwit transaction), each transaction also has a wTXID that is calculated by hashing all the data in a segwit transaction (which does includes the new fields in a segwit transaction).

So when constructing a block, a miner will now also calculate a merkle root for all of the wTXIDs in the block and include this in the block via a wTXID commitment in the coinbase transaction.

As a result, this wTXID commitment prevents anyone from modifying the witness data for the transactions included in a block.

8. Network Messages

When communicating with other nodes on the network, you now have to specifically request for a node to send you the full transaction data for segwit transactions (i.e. including the new witness data).

So whereas in a getdata message the type field would be one of the following:

• 01000000 = MSG_TX
• 02000000 = MSG_BLOCK

To request a transaction or block including the new witness data you need to use the following type fields instead:

• 01000040 = MSG_WITNESS_TX
• 02000040 = MSG_WITNESS_BLOCK

9. Other

• In addition to legacy bytes getting multiplied by 4 during the new transaction size calculation, all signature operations (e.g. OP_CHECKSIG, OP_CHECKMULTISIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIGVERIFY) in a legacy transaction are multiplied by 4 too. This is important when calculating how many signature operations are in a block, as a block has a limit of 80,000 signature operations (sigops).

Summary

As you can see, Segregated Witness introduced multiple technical changes to Bitcoin in one go.

Many of these changes also seem unnecessarily complex at first, but that's because technical workarounds were required to be able to introduce these changes as a soft fork as opposed to a hard fork.

However, depending on what you're working on, you probably do not need to include all of the changes in your software; you can just implement the changes that are relevant to your tool (e.g. you probably don't need to worry about the new network messages if you're developing a wallet).

Nonetheless, it's useful to be aware of all the changes that took place, and how they all tie together to create the biggest upgrade to Bitcoin since its release.

Implementing support for SegWit might seem like a daunting technical challenge at first, but if you work on incorporating each change as you go you'll get there eventually. Just take it one step at a time.