Follow the decisions · From address to script
P2SH: The Address That Hid Its Spending Conditions
Before P2SH, a complex way of receiving BTC created an awkward question: should the sender or the future receiver describe every spending condition? BIP 16 proposed paying a short hash of a script and revealing the complete script only at spend time. The change looked narrow, but it redistributed responsibility across a payment.
Bitcoin pays a condition
A transaction output contains a Script program that defines the next spend. A common early form required one signature for one public key, but Script could also express conditions such as two signatures out of three.
If the sender must receive and embed the full condition, the sender handles long data, pays for extra output space, and needs software support for a policy chosen by somebody else.
Paying a script hash
P2SH replaced the full output script with a small commitment: the hash must match a script later supplied by the receiver. BIP 13 provided a human-usable address encoding for that 20-byte value.
To a sender, a complex multisig wallet then looked much like an ordinary address. The sender checked its format and created a standard output without learning every key and condition.
What happens at spend time
The receiver publishes the redeemScript together with the signatures, keys, or other data needed to execute it. A node first checks that the revealed script hashes to the commitment in the old output.
It then executes that script as the spending condition. A matching hash alone is insufficient: signatures and all other rules must still pass.
Where the complexity moved
BIP 16 explicitly moved responsibility for supplying the conditions from sender to receiver. The receiver selected the protection scheme and had to preserve the redeemScript along with the keys.
That last detail mattered. Private keys alone were not enough if a wallet no longer knew which script they were meant to satisfy. Modern backups usually retain the structure, but early manual schemes required extra discipline.
Why activation was controversial
P2SH changed validation for an existing-looking output. Old nodes checked only the hash match; upgraded nodes also executed the inner script. A careless activation could therefore produce a block accepted by old software and rejected by new software.
Alternatives such as OP_EVAL were debated. BIP 16’s author described P2SH as less than elegant but argued that competing designs were riskier or harder to fit into existing address infrastructure.
How readiness was signalled
Miners were asked to put /P2SH/ in their coinbase transactions, giving observers a way to estimate support. The first activation date was postponed; the final rules applied to blocks after April 1, 2012.
A miner signal was not a vote by BTC owners and did not update user software. It helped estimate split risk when block producers needed to enforce the new condition at the same time.
The legacy of P2SH
P2SH made multisig, escrow, and other policies more practical because senders no longer needed to understand their structure. Mainnet addresses of this type commonly began with 3, although the prefix did not reveal the inner policy.
SegWit and Taproot later developed the idea of committing to hidden conditions in different forms. The broader pattern remained: publish a compact commitment when receiving and reveal required details when spending.
The sender needs a compact address. The receiver owns the conditions behind it.
Sources and verification
Historical and technical material. Do not design a custom custody script without reviewed software and a tested recovery plan.
← Back to the rubric