Home › Glossary › P2SH

P2SH

Also called: Pay to Script Hash, pay-to-script-hash, 3 address, P2SH address, redeem script, nested SegWit, P2SH-P2WPKH.

P2SH (Pay to Script Hash), defined in BIP 16, locks bitcoin to the hash of a script. Its addresses start with 3, and it carried most early multisig.

P2SH, Pay to Script Hash, lets a sender pay to a short hash of a script instead of the script itself. The receiver reveals the full script, called the redeemScript, only when spending. P2SH addresses start with 3.

How it works

BIP 16, by Gavin Andresen, defines the output script:

OP_HASH160 <20-byte script hash> OP_EQUAL

To spend, the scriptSig provides the signatures (or other data) followed by the serialized redeemScript. Nodes check that the script hashes to the stored value, then run it against the remaining data. BIP 13 defines the address: Base58Check with version byte 5 on mainnet (a leading 3) and 196 on testnet (a leading 2). The P2SH rules were enforced from April 2012 as a soft fork.

Why it mattered

Before P2SH, a sender had to put a long multisig script into their own transaction and pay for its size. BIP 16 moved that cost and complexity to the receiver: any policy, however complicated, fits behind a fixed 20-byte hash that is easy to paste or scan as a QR code. P2SH became the standard home for multisig (see BIP 45 and BIP 67), limited to 15 compressed keys because the redeemScript must fit in 520 bytes.

Nested SegWit

P2SH can also wrap a SegWit program. P2SH-P2WPKH and P2SH-P2WSH (BIP 141) gave older wallets a 3... address they could pay, while the receiver still got SegWit savings. BIP 49 defines the m/49' path and ypub keys for wrapped single-key wallets. Native SegWit addresses are cheaper to spend, but P2SH remains valid everywhere. More in the address types guide.

BIPs that define P2SH

BIP 16 (P2SH): Pay to Script Hash: Deployed. Introduced Pay to Script Hash (P2SH), letting a sender pay to a short fingerprint of spending rules that the recipient reveals only when spending. This shifted the cost and complexity of setups like…
BIP 13 (P2SH addresses): Address Format for pay-to-script-hash: Deployed. Defines the address format for pay-to-script-hash, the addresses that begin with "3". Such an address stands for a hidden set of spending rules, so people can pay into arrangements like multisig as…
BIP 141 (SegWit): Segregated Witness (Consensus layer): Deployed. Defines Segregated Witness (SegWit), which moves signatures into a separate "witness" section of each transaction while remaining compatible with older nodes. This fixed transaction malleability,…
BIP 49 (nested SegWit derivation): Derivation scheme for P2WPKH-nested-in-P2SH based accounts: Deployed. Defines how HD wallets derive keys for SegWit addresses wrapped inside P2SH, which begin with "3". This let wallets offer cheaper SegWit transactions while staying payable from older software that…
BIP 45: Structure for Deterministic P2SH Multisignature Wallets: Complete. Defines a key structure for HD wallets shared among several co-signers using P2SH multisig. It lets each participant independently generate the same series of shared addresses without exchanging new…
BIP 67: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting: Complete. Specifies sorting the public keys in a multisig setup into a fixed order, so the same keys always produce the same P2SH address. Co-signers can then independently compute matching addresses without…

Related terms

Multisig: Multisig (multi-signature) locks bitcoin so that M of N chosen keys must sign to spend it, for example any 2 of 3 keys kept in different places.
P2WSH: P2WSH (Pay to Witness Script Hash) is the native SegWit output for scripts such as multisig: a 32-byte script hash with a 62-character bc1q address.
P2WPKH: P2WPKH (Pay to Witness Public Key Hash) is the native SegWit single-key output type. Its bc1q addresses are always 42 characters long.
Base58Check: Base58Check is the original text encoding for Bitcoin addresses and keys: Base58 characters plus a 4-byte checksum from double SHA-256.
Soft fork: A soft fork is a backward-compatible change to Bitcoin's consensus rules that only tightens them, so old nodes still accept the new blocks.