Overview
Pay-to-Script-Hash (P2SH), introduced in BIP16, shifted the burden of complex spending conditions from the sender to the recipient. Before P2SH, if someone wanted to receive bitcoin to a multisig arrangement, the sender had to include the entire multisig script in their transaction output. P2SH simplified this by allowing the recipient to provide just a hash of the script, with the full script revealed only at spending time.
How P2SH Works
The sender locks funds to the hash of a redeem script. When spending, the recipient reveals the full redeem script along with the data required to satisfy it.
Locking Script:
OP_HASH160 <scriptHash> OP_EQUAL
Unlocking Script (spending a 2-of-3 multisig):
OP_0 <sig1> <sig2> <redeemScript>
Where redeemScript =
OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3 OP_CHECKMULTISIG
Validation:
┌────────────────────┐
│ 1. Hash the │
│ redeemScript │──> Must match <scriptHash>
├────────────────────┤
│ 2. Execute the │
│ redeemScript │──> Must return TRUE
│ with provided │
│ signatures │
└────────────────────┘
Address Format
P2SH addresses use Base58Check encoding and begin with the character 3 on mainnet. This makes it easy for wallets to distinguish P2SH from P2PKH addresses (which start with 1).
Common Use Cases
- Multisig wallets — The most common P2SH use case, enabling m-of-n signing requirements
- Wrapped SegWit — P2SH can wrap a SegWit script (
P2SH-P2WPKH), allowing older wallets to send to SegWit addresses - Timelocked scripts — Escrow or vesting arrangements using
OP_CHECKLOCKTIMEVERIFY
Limitations
P2SH requires revealing the full redeem script when spending, which exposes the spending conditions on-chain. The newer P2TR (Taproot) format addresses this privacy concern by only revealing the specific spending path that was used, keeping unused conditions hidden.