Documentation

Transaction Structure

Overview

P2WSH transactions store all script and signature data in the witness field, leaving the ScriptSig empty.

Output (Locking Script - ScriptPubKey)

The ScriptPubKey for P2WSH consists of the witness version and the 32-byte script hash.

The following diagram shows the P2WSH ScriptPubKey structure:
P2WSH ScriptPubKey Structure OP_0 0x00 (version 0) OP_PUSHBYTES_32 0x20 Script Hash 32 bytes (SHA-256 of witness script) 34 bytes total (1 + 1 + 32)
The following code shows a typical P2WSH ScriptPubKey script:
plaintext
OP_0
OP_PUSHBYTES_32
1863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262

# Hex value: 00201863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262

Input (Unlocking Script - ScriptSig)

For native P2WSH, the ScriptSig is empty.

All signature and script data is stored in the witness field.

Witness Data

The witness data follows a specific serialization format. It begins with the number of stack items as a single byte, followed by each item's size and value in sequence.

The following diagram shows the P2WSH witness data structure:
P2WSH Witness Data Structure Count 0x04 Size varint Item 1 n bytes Size varint Item 2 n bytes Size varint Item 3 n bytes Size varint Witness Script n bytes Last item is always the witness script. SHA256(witness script) must match the 32-byte hash in scriptPubKey.

For a 2-of-3 multisig P2WSH, the witness contains: [dummy element][signatures][witness script].

The following example shows a typical P2WSH witness data field for a 2-of-3 multisig:
plaintext
04                                          # Item count (4 items)
00                                          # First item size (0 bytes - empty dummy element)
                                            # First item value: (none - empty for CHECKMULTISIG bug)
48                                          # Second item size (72 bytes)
3045022100...01                             # Second item value: First signature + SIGHASH
48                                          # Third item size (72 bytes)
304402...01                                 # Third item value: Second signature + SIGHASH
69                                          # Fourth item size (105 bytes)
522102...53ae                               # Fourth item value: Witness script (2-of-3 multisig)

Script Execution

When validating a P2WSH transaction, the script execution occurs in two phases:

  1. Script Hash Verification
    • The witness script (last item in witness data) is hashed using SHA-256.
    • The computed hash is compared against the 32-byte script hash in the ScriptPubKey.
  2. Witness Script Execution
    • If the hashes match, the witness script is deserialized into its component opcodes.
    • The script is executed with the remaining witness items as stack inputs.
    • If the hashes do not match, the transaction fails immediately.
Note

The execution trace varies depending on the type of witness script used:

  • A 2-of-3 multisig script requires signature verification against multiple public keys.
  • A timelock script involves time comparison operations.
  • A HTLC script performs hash verification with conditional branches.

Each script type defines its own set of opcodes and stack operations.

Execution Trace

The example below demonstrates execution for a 2-of-3 multisig script.

Phase 1: Witness Script Hash Verification

The following diagram illustrate the witness script hash verification:
P2WSH Witness Script Hash Verification (No Stack Execution) 1. Version Detection 2. Extract Witness Script 3. Hash Witness Script 4. Compare Hashes ScriptPubKey OP_0 <32 bytes hash> SegWit v0 + 32 bytes P2WSH detected triggers P2WSH rules Witness Data OP_0 sig1 sig2 script <witness script> last item extracted <witness script> SHA-256 ScriptPubKey 32 bytes hash =? Computed SHA-256 If Match continue to Phase 2
  1. Witness Version Detection
    The node recognizes witness version 0 with a 32-byte program in the ScriptPubKey, triggering P2WSH validation rules.
  2. Extract Witness Script
    The last item in the witness data is identified as the witness script and saved for execution.
  3. Hash Witness Script
    Apply SHA-256 to the witness script, producing a 32-byte hash.
  4. Compare Hashes
    Compare the computed hash with the 32-byte script hash from the ScriptPubKey. If they do not match, the transaction fails immediately.

Phase 2: Witness Script Execution

The following diagram illustrate the witness script execution stack:
P2WSH Witness Script Execution (2-of-3 Multisig) Initial Stack from witness OP_2 req sigs Push Keys <pk1><pk2><pk3> OP_3 total keys CHECKMULTISIG 0xae Result Final OP_0 (dummy) <sig 1> <sig 2> top OP_0 (dummy) <sig 1> <sig 2> 2 top OP_0 (dummy) <sig 1> <sig 2> 2 <pk1> <pk2> <pk3> top OP_0 (dummy) <sig 1> <sig 2> 2 <pk1> <pk2> <pk3> 3 top consumed consumed consumed consumed consumed consumed consumed consumed 1 top → → → → →
  1. Push Dummy Element
    Push the empty element from the witness data onto the stack. This dummy element is required due to a bug in OP_CHECKMULTISIG.
  2. Push First Signature
    Push the first DER-encoded signature with SIGHASH suffix from the witness data onto the stack.
  3. Push Second Signature
    Push the second DER-encoded signature with SIGHASH suffix from the witness data onto the stack.
  4. Deserialize Witness Script
    The witness script is deserialized into its component opcodes.
  5. Push Required Signature Count
    Push the number 2 onto the stack, indicating the minimum number of signatures required.
  6. Push Public Keys
    Push all three public keys from the witness script onto the stack.
  7. Push Total Key Count
    Push the number 3 onto the stack, indicating the total number of public keys.
  8. Verify Multisig
    Verify that 2 valid signatures exist for any 2 of the 3 public keys. The dummy element is consumed due to the off-by-one bug. If verification succeeds, 1 is pushed onto the stack.
  9. Result
    If the final stack contains 1, the transaction is valid and the funds are unlocked.
On this page