P2SH address

Pay to script hash arrived with BIP-16, enforced from block 173,805 on April 1, 2012, and it changed who carries the cost of complexity. Before it, a sender had to write the whole contract into the output. After it, the sender writes 23 bytes and the recipient pays to reveal the script later, which is why a 3 address can conceal a five-key vault or a plain single-key wallet.

How it works

The output script is short and identical for every P2SH address: OP_HASH160 followed by a 20-byte hash and OP_EQUAL, 23 bytes in total. The hash commits to a redeem script that only the recipient knows.

Spending happens in two passes. The scriptSig supplies the arguments the redeem script needs, then the serialized redeem script itself as the final item. A node hashes that last item, checks it against the committed value, and if they match it deserializes the script and runs it against everything left on the stack. Both stages have to succeed.

Two limits shape what fits. A redeem script is a single stack element, so it cannot exceed the 520-byte push limit that Bitcoin Core defines as MAX_SCRIPT_ELEMENT_SIZE. Relay policy adds a second ceiling of 15 signature operations per P2SH input. Together they cap the arrangement well below what the script language allows in general, where the limit is a 10,000-byte script.

The address itself is Base58Check with a version byte of 0x05, which produces the leading 3 and a string of 34 characters. BIP-13 defined that format, separately from the consensus rule in BIP-16.

Where you see it

Exchange withdrawal forms that describe an option as "SegWit" without saying "native" usually mean a 3 address. Multisig vaults built before 2018 use them. So do atomic swaps and hashed timelock contracts that need a script but want an address a plain wallet can pay.

The consequence of the design is ambiguity, and it is total. An unspent 3 output reveals only a hash, so a block explorer cannot tell you whether it holds a wrapped single key or a corporate quorum, and neither can the sender. The information only appears in the spending transaction.

That ambiguity carries a real loss mode. Recovering coins from a P2SH output needs the redeem script, not only the private keys. A seed phrase alone will not rebuild an arbitrary script, so any P2SH arrangement more elaborate than a standard wallet derivation has to be backed up as a descriptor or as the script bytes themselves. People have lost coins holding every key and no script.

P2SH address vs P2SH multisig

P2SH multisig is one thing you can put inside a P2SH address, not a synonym for the format. The address is a container, and the redeem script hiding in it might be an m-of-n multisig, a nested SegWit key hash, a timelocked recovery clause, or a script nobody else has ever written. Reading a 3 address as "a multisig address" is a guess that fails often, because wrapped SegWit made 3 the default single-key format for several years after 2017 and left millions of ordinary wallets sitting behind that prefix.