Pay-to-Script-Hash Mechanics (P2SH — BIP 16)

While native multisig works perfectly inside Bitcoin’s virtual machine, deploying raw multisig scripts directly into transaction outputs introduced massive real-world problems.

To solve this, developers activated Pay-to-Script-Hash (P2SH) via a soft fork in 2012 (formalized in BIP 16).

The Problems with Raw Native Multisig

Before P2SH, if a merchant wanted to use a 2-of-3 multisig wallet for safety, anyone paying that merchant had to construct a massive, non-standard transaction output:

OP_2 <PubKey_A> <PubKey_B> <PubKey_C> OP_3 OP_CHECKMULTISIG

This model had three severe flaws:

1. Sender Burden: Senders had to pay significantly higher transaction fees because the output (scriptPubKey) was massive, and fee costs are determined by transaction data size.

2. Inconvenience: The sender had to know all three of the receiver’s public keys and understand the exact script layout just to send a basic payment.

3. UTXO Bloat: Because these outputs contained large public keys, they took up a massive amount of space inside full nodes' RAM-cached chainstate databases.

The Solution: Pay-to-Script-Hash (P2SH)

P2SH shifts the burden of complex scripts from the sender to the receiver.

Instead of sending coins to a massive, complex lock, the sender locks the coins to a simple 20-byte cryptographic hash of the spending script (which we call the Redeem Script).

• The sender's scriptPubKey becomes incredibly standard, short, and cheap:

OP_HASH160 <20-Byte-RedeemScriptHash> OP_EQUAL

• This compiles into a clean address starting with the number 3. To the sender, paying a complex 15-key multisig looks exactly like paying a standard single-key address!

 NATIVE MULTISIG (SENDER PAYS FOR BLOAT)
┌────────────────────────────────────────────────────────────────────────┐
│ scriptPubKey: OP_2 <PubKeyA> <PubKeyB> <PubKeyC> OP_3 OP_CHECKMULTISIG │
└───────────────────────────────────┬────────────────────────────────────┘
 │ (Huge byte footprint in output)
 ▼
 P2SH (RECEIVER PAYS FOR BLOAT)
┌────────────────────────────────────────────────────────────────────────┐
│ scriptPubKey: OP_HASH160 <RedeemScriptHash> OP_EQUAL │
└───────────────────────────────────┬────────────────────────────────────┘
 │ (Tiny, standard output footprint)
 ▼

How P2SH Validation Works (Two-Step Execution)

When the receiver wants to spend the P2SH output, they must present the raw signatures AND the full serialized Redeem Script inside their input’s scriptSig:

• scriptSig (Input): <Sig_A> <Sig_C> <Serialized_RedeemScript>

A validating full node executes the verification process in two distinct, sequential phases:

 P2SH VALIDATION CYCLE
┌────────────────────────────────────────────────────────────────────────┐
│ PHASE 1: THE HASH CHECK │
├────────────────────────────────────────────────────────────────────────┤
│ • Node executes: OP_HASH160 <RedeemScriptHash> OP_EQUAL │
│ • It hashes the Serialized_RedeemScript from the spender. │
│ • Checks if Hash(RedeemScript) == RedeemScriptHash in the output. │
└───────────────────────────────────┬────────────────────────────────────┘
 │
 ├───► [FAIL] ──► Tx Rejected
 │
 ▼ [PASS]
┌────────────────────────────────────────────────────────────────────────┐
│ PHASE 2: REDEEM SCRIPT EXECUTION │
├────────────────────────────────────────────────────────────────────────┤
│ • Node deserializes the Serialized_RedeemScript bytes back into Opcodes│
│ • Executes the script: OP_2 <PubA> <PubB> <PubC> OP_3 OP_CHECKMULTISIG │
│ • Runs this script using the remaining signatures: [0, Sig_A, Sig_C] │
└───────────────────────────────────┬────────────────────────────────────┘
 │
 ▼
 Is Final Execution = 1?
 [YES] ──► Spend Approved (Valid)
 [NO] ──► Transaction Rejected (Invalid)

Key Benefits of P2SH

• Fairness: The receiver of the complex script is the one who has to provide the massive signature and redeem script bytes during spending. Therefore, the receiver pays the high transaction fee, which is appropriate since they are the ones choosing to use multisig.

• Abstraction: Senders do not need to know whether they are paying a single user, a 2-of-3 multisig escrow, or a 15-of-15 corporate vault. To the sender, it is just a standard "3-address."

• Upgradability: P2SH paved the way for soft-forking complex scripts and structures (like SegWit) into the network without requiring hard-fork consensus changes.