Pay-to-Script-Hash (P2SH)

Pay-to-Script-Hash (P2SH) is a Bitcoin output type defined in BIP 16 that locks coins to the hash of a script rather than to the script itself. The full script — called the redeem script — is revealed only when the funds are spent. P2SH was activated as a soft fork on 1 April 2012 and uses base58 addresses that begin with the digit 3, still instantly recognizable across the ecosystem more than a decade later.

How P2SH works

A P2SH locking script is compact and fixed-length: OP_HASH160, a 20-byte script hash, and OP_EQUAL. To spend, the redeemer provides, in the unlocking script, the data needed to satisfy the redeem script followed by the serialized redeem script itself. Validation runs in two phases on the script stack: the network first confirms the supplied redeem script hashes to the committed 20-byte value, then executes that redeem script against the remaining stack items to verify the spend. The hash commitment is the trick — the blockchain never needs to know what the script says until the moment it is exercised, exactly like committing to a sealed envelope whose contents are checked only when opened.

Why it was a breakthrough

Before P2SH, a sender paying into a complex contract such as multisig had to embed the entire script in their output — meaning the sender needed to know the full script, paid fees for its size, and exposed the spending policy to the world immediately. P2SH inverted all three burdens onto the redeemer, where they belong: the sender only needs a short standard address, so paying into a 3-of-5 multisig became as simple as paying anyone else. This unlocked practical multisignature custody, timelocked vaults using opcodes like OP_CHECKLOCKTIMEVERIFY (CLTV), and cross-chain atomic swap contracts for everyday wallets. It also improved privacy and fee fairness: the policy stays hidden until spend time, and the party with the elaborate requirements is the one who pays for their on-chain weight.

Legacy and the path to SegWit and Taproot

The same wrapping pattern later carried Bitcoin through its most important upgrade transition: "nested SegWit" put a witness program inside a P2SH redeem script, letting SegWit-aware wallets receive from older wallets that only understood addresses starting with 3. The conceptual lineage continues today — native SegWit outputs commit to script hashes directly (P2WSH), and Taproot pushes the idea further by hiding an entire tree of alternative scripts behind what looks like a single public key, revealing only the branch actually used. Each step refines the same P2SH insight: commit to the contract, reveal only what executes.

Why it still matters to sovereign users

P2SH remains everywhere in practice: countless multisig treasuries, inherited wallet configurations, and swap protocols still live behind addresses starting with 3, and any Bitcoin Script education worth having includes tracing a P2SH spend by hand. For self-custody, it marks the moment Bitcoin's contract capability became usable by ordinary holders — the point where "your keys" could mean two-of-three keys in separate locations without asking anyone's permission or paying a custodian to arrange it.

Handling P2SH on your own bench

Practical sovereignty with P2SH is mostly about custody hygiene. If you hold coins behind a 3-address — a legacy multisig, an old swap, an inherited wallet — the redeem script is part of your backup, full stop: the address hash alone cannot reconstruct the spending conditions, so a seed phrase without the accompanying script details (or the wallet descriptor that encodes them) can leave funds visible but unspendable. Modern descriptor-based wallets solve this by making the full policy part of the backup format, which is one of the quiet reliability upgrades of the last several years. When consolidating old holdings, sweeping P2SH outputs to current output types during low-fee periods simplifies every future recovery you or your heirs will attempt.