SegWit

Segregated Witness was an update to the Bitcoin consensus rules and network protocol that was activated on mainnet on August 1, 2017.

Witness is referred to that which satisfies the cryptographic conditions placed in the UTXO.

Before segwit, witness data was embedded in the transaction as part of each input. The term segwit implies that we are segregating the witness from the transaction.

Segregated Witness is a change to Bitcoin that aims to move the witness data from the scriptSig field of a transaction to a separate witness data structure that accompanies the transaction.

Why segwit?

Transaction Malleability

With segwit transaction hashes become immutable to anyone but the creator which has downstream effects for advanced transaction construction.

Script Versioning

Every locking script is preceeded by a script version number. This allows the scripting language to be upgraded in a backward-compatible way.

Network and Storage Scaling

The witness data is often a big contributor to the size of the transaction especially for multisigs and complex transactions with payment channels. By segregating the witness data, nodes can prune the witness data after validating the signature.

Signature verification optimization

Segwit upgraded signature functions to reduce complexity from \(O(n^2)\) to \(O(n)\) where n is number of signatures.

Offline Signature Improvement

Segwit signatures incorporate the value of each input in the hash that is signed. This makes streaming a large amount of data about previous transactions referenced as inputs redundant, improving offline signing.

Since the amount is now part of the commitment hash that is signed, an offline device does not need the previous transactions. If the amounts do not match (are misrepresented by a compromised online system), the signature will be invalid

Segwit Transactions

P2WPKH

A simple P2PKH out script look like:

DUP HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 EQUALVERIFY CHECKSIG

and the transaction data would look like:

[...]
“Vin” : [
"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
"vout": 0,
         "scriptSig": “<Bob’s scriptSig>”,
]
[...]

With a segwit Pay-to-Witness-Public-Key-Hash this would look like:

0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7

The first number (0) is interpreted as a version number (the witness version) and the second part (20 bytes) is the equivalent of a locking script known as a witness program.

The 20-byte witness program is simply the hash of the public key, as in a P2PKH script.

The transaction data looks like:

[...]
“Vin” : [
"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
"vout": 0,
         "scriptSig": “”,
]
[...]
“witness”: “<Bob’s witness data>”
[...]

Note there is no signature in the Vin, whereas a separate witness field is present.

P2WSH

A simple P2SH out script look like:

HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e EQUAL

and the transaction data would look like:

[...]
“Vin” : [
"txid": "abcdef12345...",
"vout": 0,
     "scriptSig": “<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>”,
]

With a segwit Pay-to-Witness-Script-Hash this would look like:

0 a9b7b38d972cabc7961dbfbcb841ad4508d133c47ba87457b4a0e8aae86dbb89

The first number (0) is interpreted as a version number (the witness version) and the second part (32 bytes) hash of the hash of the redeem script.

The 20-byte witness program is simply the hash of the public key, as in a P2PKH script.

The transaction data looks like:

[...]
“Vin” : [
"txid": "abcdef12345...",
"vout": 0,
         "scriptSig": “”,
]
[...]
“witness”: “<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>”
[...]

Upgrading to segwit

Not all wallets and user facing applications will move to segwit at the same time. Backward compatibility needs to maintained.

Differentiating between P2WPKH and P2WSH

The critical difference between them is the length of the hash:

  1. The public key hash in P2WPKH is 20 bytes
  2. The script hash in P2WSH is 32 bytes

Segwit scripts inside P2SH

This is made simpler by the fact that both form of witness scripts can be embedded inside the a P2SH address.

The users wallet creates a witness program. This witness program is then hashed. The resulting hash is embedded inside a P2SH script.

The P2SH hash is converted to a Bitcoin address(one that starts with a 3). This address can be shared be shared with anyone who wants to make a payment to the user, as if sending to a normal Bitcoin address.

This way both P2WSH and P2WPKH type payments can be used inside P2SH.

Doubts

  1. How does a legacy client see segwit transactions?