Segregated Witness (Consensus layer)

  BIP: 141
  Layer: Consensus (soft fork)
  Title: Segregated Witness (Consensus layer)
  Authors: Eric Lombrozo 
           Johnson Lau 
           Pieter Wuille 
  Status: Deployed
  Type: Specification
  Assigned: 2015-12-21
  License: PD

Abstract

This BIP defines a new structure called a "witness" that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but not required to determine transaction effects. In particular, scripts and signatures are moved into this new structure.

The witness is committed in a tree that is nested into the block's existing merkle root via the coinbase transaction for the purpose of making this BIP soft fork compatible. A future hard fork can place this tree in its own branch.

Motivation

The entirety of the transaction's effects are determined by output consumption (spends) and new output creation. Other transaction data, and signatures in particular, are only required to validate the blockchain state, not to determine it.

By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:

# Nonintentional malleability becomes impossible. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach (BIP62): #* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation) #* In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62) #* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability #* It allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the Lightning Network # Transmission of signature data becomes optional. It is needed only if a peer is trying to validate a transaction instead of just checking its existence. This reduces the size of SPV proofs and potentially improves the privacy of SPV clients as they can download more transactions using the same bandwidth. # Some constraints could be bypassed with a soft fork by moving part of the transaction data to a structure unknown to current protocol, for example: #* Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent #* Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed #* New script system could be introduced without any limitation from the existing script semantic. For example, a new transaction digest algorithm for transaction signature verification is described in BIP143

Specification

Transaction ID

A new data structure, witness, is defined. Each transaction will have 2 IDs.

Definition of txid remains unchanged: the double SHA256 of the traditional serialization format:

[nVersion][txins][txouts][nLockTime]

A new wtxid is defined: the double SHA256 of the new serialization with witness data:

[nVersion][marker][flag][txins][txouts][witness][nLockTime]

Format of nVersion, txins, txouts, and nLockTime are same as traditional serialization.

The marker MUST be a 1-byte zero value: 0x00.

The flag MUST be a 1-byte non-zero value. Currently, 0x01 MUST be used.

The witness is a serialization of all witness fields of the transaction. Each txin is associated with a witness field. A witness field starts with a var_int to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a var_int to indicate the length. Witness data is NOT script.

A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a 0x00. If all txins are not witness program, a transaction's wtxid is equal to its txid.

Commitment structure

A new block rule is added which requires a commitment to the wtxid. The wtxid of coinbase transaction is assumed to be 0x0000....0000.

A witness root hash is calculated with all those wtxid as leaves, in a way similar to the hashMerkleRoot in the block header.

The commitment is recorded in a scriptPubKey of the coinbase transaction. It must be at least 38 bytes, with the first 6-byte of 0x6a24aa21a9ed, that is:

1-byte - OP_RETURN (0x6a) 1-byte - Push the following 36 bytes (0x24) 4-byte - Commitment header (0xaa21a9ed) 32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value)

39th byte onwards: Optional data with no consensus meaning

and the coinbase's input's witness must consist of a single 32-byte array for the witness reserved value.

If there are more than one scriptPubKey matching the pattern, the one with highest output index is assumed to be the commitment.

If all transactions in a block do not have witness data, the commitment is optional.

Witness program

A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (one of OP_0,OP_1,OP_2,...,OP_16) followed by a direct data push between 2 and 40 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program". In more detail, this means a scriptPubKey or redeemScript which consists of (in order):

• First, byte 0x00 (OP_0) or any byte between 0x51 (OP_1) and 0x60 (OP_16) inclusive (the version byte).
• Then, a byte L between 0x02 (push of 2 bytes) and 0x28 (push of 40 bytes) inclusive.
• Finally, L arbitrary bytes (the witness program).

There are two cases in which witness validation logic are triggered. Each case determines the location of the witness version byte and program, as well as the form of the scriptSig: # Triggered by a scriptPubKey that is exactly a push of a version byte, plus a push of a witness program. The scriptSig must be exactly empty or validation fails. ("native witness program") # Triggered when a scriptPubKey is a P2SH script, and the BIP16 redeemScript pushed in the scriptSig is exactly a push of a version byte plus a push of a witness program. The scriptSig must be exactly a push of the BIP16 redeemScript or validation fails. ("P2SH witness program")

If the version byte is 0, and the witness program is 20 bytes (L = 20):

• It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program.
• The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key.
• The HASH160 of the public key must match the 20-byte witness program.
• After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack.

If the version byte is 0, and the witness program is 32 bytes (L = 32):

• It is interpreted as a pay-to-witness-script-hash (P2WSH) program.
• The witness must consist of an input stack to feed to the script, followed by a serialized script (witnessScript).
• The witnessScript (≤ 10,000 bytes) is popped off the initial witness stack. SHA256 of the witnessScript must match the 32-byte witness program.
• The witnessScript is deserialized, and executed after normal script evaluation with the remaining witness stack (≤ 520 bytes for each stack item).
• The script must not fail, and result in exactly a single TRUE on the stack.

If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.

If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions.

Other consensus critical limits

Block size

Blocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows:

Block weight is defined as Base size * 3 + Total size. (rationale)

Base size is the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node.

Total size is the block size in bytes with transactions serialized as described in BIP144, including base data and witness data.

The new rule is block weight ≤ 4,000,000.

Sigops

Sigops per block is currently limited to 20,000. We change this restriction as follows:

Sigops in the current pubkey script, signature script, and P2SH check script are counted at 4 times their previous value. The sigop limit is likewise quadrupled to ≤ 80,000.

Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH witnessScript are counted identically as previously within the P2SH redeemScript. That is, CHECKSIG is counted as only 1 sigop. When preceded by OP_1 to OP_16 CHECKMULTISIG is counted as 1 to 16 sigops respectively, otherwise it is counted as 20 sigops. This rule applies to both native witness program and P2SH witness program.

Additional definitions

The following definitions are not used for consensus limits, but are suggested to provide language consistent with the terminology introduced above.

Transaction size calculations

Transaction weight is defined as Base transaction size * 3 + Total transaction size (ie. the same method as calculating Block weight from Base size and Total size).

Virtual transaction size is defined as Transaction weight / 4 (rounded up to the next integer).

Base transaction size is the size of the transaction serialised with the witness data stripped.

Total transaction size is the transaction size in bytes serialized as described in BIP144, including base data and witness data.

New script semantics

Despite that the script language for P2WPKH and P2WSH looks very similar to pre-segregated witness script, there are several notable differences. Users MUST NOT assume that a script spendable in pre-segregated witness system would also be spendable as a P2WPKH or P2WSH script. Before large-scale deployment in the production network, developers should test the scripts on testnet with the default relay policy turned on, and with a small amount of money after BIP141 is activated on mainnet.

A major difference at consensus level is described in BIP143, as a new transaction digest algorithm for signature verification in version 0 witness program.

Three relay and mining policies are also included in the first release of segregated witness at reference implementation version 0.13.1. Softforks based on these policies are likely to be proposed in the near future. To avoid indefinite delay in transaction confirmation and permanent fund loss in a potential softfork, users MUST observe the new semantics carefully:

# Only compressed public keys are accepted in P2WPKH and P2WSH (See BIP143) # The argument of OP_IF/NOTIF in P2WSH must be minimal # Signature(s) must be null vector(s) if an OP_CHECKSIG or OP_CHECKMULTISIG is failed (for both pre-segregated witness script and P2WSH. See BIP146)

Examples

P2WPKH

The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH):

witness: scriptSig: (empty) scriptPubKey: 0 <20-byte-key-hash> (0x0014{20-byte-key-hash})

The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WPKH type. The witness must consist of exactly 2 items. The HASH160 of the pubkey in witness must match the witness program.

The signature is verified as

CHECKSIG

Comparing with a traditional P2PKH output, the P2WPKH equivalent occupies 3 less bytes in the scriptPubKey, and moves the signature and public key from scriptSig to witness.

P2WPKH nested in BIP16 P2SH

The following example is the same P2WPKH, but nested in a BIP16 P2SH output.

witness: scriptSig: <0 <20-byte-key-hash>> (0x160014{20-byte-key-hash}) scr