Documentation

Transaction Structure

Overview

P2SH transactions have a unique structure where the redeem script is provided in the input rather than being embedded in the output.

Output (Locking Script - ScriptPubKey)

The ScriptPubKey for P2SH is standardized and contains only the script hash.

The following diagram shows the P2SH ScriptPubKey structure:
P2SH ScriptPubKey Structure OP_HASH160 0xa9 OP_PUSHBYTES_20 0x14 Script Hash 20 bytes (HASH160 of redeem script) OP_EQUAL 0x87
The following code shows a typical P2SH ScriptPubKey script:
plaintext
OP_HASH160
OP_PUSHBYTES_20
89abcdefabbaabbaabbaabbaabbaabbaabbaabba
OP_EQUAL

# Hex value: a91489abcdefabbaabbaabbaabbaabbaabbaabbaabba87

Input (Unlocking Script - ScriptSig)

The ScriptSig contains the data required to satisfy the redeem script, followed by the serialized redeem script itself.

The following diagram shows the P2SH ScriptSig structure:
P2SH ScriptSig Structure Script Input 1 Script Input 2 ... Serialized Redeem Script
The following code shows a typical P2SH ScriptSig script for 2-of-3 Multisig:
plaintext
OP_0 
OP_PUSHBYTES_72 3044022041b2a8a8e6c0c8e5b1c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f022012a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708101
OP_PUSHBYTES_71 304402207e8495b6a9c8d3f1a2b4c5d6e7f8091a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f02201a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b01
OP_PUSHDATA1 69 522102a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7a8b9c0d1e2f3a42103b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7a8b9c0d1e2f3a4b52103c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7a8b9c0d1e2f3a4b5c53ae

Components:

  • OP_0: Dummy element required due to a bug in OP_CHECKMULTISIG.
  • <signature 1>: First DER-encoded signature with SIGHASH suffix.
  • <signature 2>: Second DER-encoded signature with SIGHASH suffix.
  • <redeem script>: The serialized 2-of-3 multisig script.

Script Execution

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

  1. Script Hash Verification
    • The serialized redeem script is hashed.
    • The computed hash is compared against the script hash in the ScriptPubKey.
  2. Redeem Script Execution
    • If the hashes match, the redeem script is deserialized.
    • The script is executed with the remaining ScriptSig elements as inputs.
    • If the hashes do not match, the transaction fails immediately.
Note

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

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

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, which is one of the most common P2SH use cases.

Phase 1: Redeem Script Hash Verification

The following diagram illustrate the redeem script hash verification:
P2SH Redeem Script Hash Verification ScriptSig Initial OP_HASH160 0xa9 Push <hash> from scriptPubKey OP_EQUAL 0x87 Verify & Continue to phase 2 OP_0 (dummy) <sig 1> <sig 2> <redeem script> top saved for P2 OP_0 (dummy) <sig 1> <sig 2> <script hash> top OP_0 (dummy) <sig 1> <sig 2> <script hash> <expected hash> top OP_0 (dummy) <sig 1> <sig 2> 1 top OP_0 (dummy) <sig 1> <sig 2> top 1 verified popped, continue → → → →
  1. Push Dummy Element
    Push OP_0 onto the stack. This dummy element is required due to a bug in OP_CHECKMULTISIG that consumes an extra stack element.
  2. Push First Signature
    Push the first 72-byte DER-encoded signature with SIGHASH suffix onto the stack.
  3. Push Second Signature
    Push the second 71-byte DER-encoded signature with SIGHASH suffix onto the stack.
  4. Push Redeem Script
    Push the serialized redeem script onto the stack.
  5. Save Redeem Script (P2SH Rule)
    Before executing the ScriptPubKey, the P2SH consensus rules save a copy of the top stack element (the serialized redeem script) for later execution. This happens outside the stack.
  6. Hash Redeem Script
    Pop the redeem script from the stack, apply SHA-256 followed by RIPEMD-160, and push the resulting 20-byte hash.
  7. Push Expected Hash
    Push the 20-byte expected script hash from the ScriptPubKey onto the stack.
  8. Compare Hashes
    Compare the computed hash with the expected hash. If they do not match, the script fails immediately. Both hash values are consumed and the result is pushed onto the stack.

Phase 2: Redeem Script Execution

The following diagram illustrate the redeem script execution stack:
P2SH Redeem Script Execution Initial Stack from Phase 1 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. Verify and Prepare
    The P2SH consensus rules verify that Phase 1 completed successfully (stack top is 1). The 1 value is removed, and the previously saved redeem script is deserialized into its component opcodes:
    • OP_2
    • <pubkey1>
    • <pubkey2>
    • <pubkey3>
    • OP_3
    • OP_CHECKMULTISIG
  2. Push Required Signature Count
    Push the number 2 onto the stack, indicating the minimum number of signatures required.
  3. Push Public Keys
    Push all three public keys from the redeem script onto the stack.
  4. Push Total Key Count
    Push the number 3 onto the stack, indicating the total number of public keys.
  5. Verify Multisig
    Verify that 2 valid signatures exist for any 2 of the 3 public keys. The dummy OP_0 element is consumed due to the off-by-one bug. If verification succeeds, 1 is pushed onto the stack.
  6. Result
    If the final stack contains 1, the transaction is valid and the funds are unlocked.
Note
The P2SH execution model involves special consensus rules that operate outside the normal stack-based script execution. The redeem script is saved separately before the ScriptPubKey executes and is only run after the hash verification succeeds. This two-phase approach is unique to P2SH and is enforced at the consensus level.
On this page