P2SH locks bitcoin to the hash of a script that is revealed only when spending, giving complex conditions a short address. Learn how it works.
Hide the complexity behind a hash
Before 2012, paying to a multisig meant the sender had to put the whole long script into their transaction. P2SH (BIP 16) flipped that: the output holds only a 20-byte hash of the script.
Locking: OP_HASH160 <script hash> OP_EQUAL
Unlocking: <data needed by the script> <redeem script>Two checks
- The revealed redeem script must hash to the value in the output.
- The redeem script is then run with the rest of the unlocking data, and it must succeed.
Benefits
- Senders don't care how complicated the conditions are: they just pay to a "3…" address.
- The spender pays for the larger script, not the sender.
- Wrapped SegWit: P2SH can contain a SegWit program, so older wallets could pay SegWit users. These are "nested SegWit" addresses.
Nested SegWit
Many 3… addresses are SegWit wallets in disguise. The redeem script is a tiny SegWit program, letting older wallets that couldn't send to bc1 addresses pay SegWit users. Now that bc1 support is universal, native SegWit is cheaper.
A size limit
The redeem script in P2SH is limited to 520 bytes, which caps legacy multisig at around 15 keys. P2WSH and Taproot raised these limits.
Key takeaways
- P2SH locks coins to the hash of a script.
- The script and its inputs are revealed only when spending.
- P2SH addresses start with 3.
Common questions
Is every 3… address multisig?
No. It could be any script, including wrapped SegWit single-key addresses.
What is P2WSH?
The SegWit version of P2SH, using a 32-byte SHA-256 hash and witness data.
Is every 3… address multisig?
No. Many are nested SegWit single-key wallets.
When was P2SH introduced?
In 2012 through BIP 16, as a soft fork.