P2SH (Pay-to-Script-Hash)

What Is P2SH?

Pay-to-Script-Hash (P2SH) is a Bitcoin transaction type where the sender pays to the hash of a redeem script rather than directly to a public key or public key hash. The actual spending conditions are hidden until the recipient spends the funds, at which point they reveal and satisfy the original script. This approach was introduced in BIP-16, authored by Gavin Andresen, and activated on the Bitcoin network on April 1, 2012 at block height 173,805.

Before P2SH, anyone sending to a multisig address had to include the full multisig script in their transaction output. This made complex transactions expensive for senders and exposed the spending conditions on-chain before the funds were spent. P2SH shifts that burden to the recipient: the sender only needs a fixed-length 20-byte hash, regardless of how complex the underlying Bitcoin Script is. For a deeper look at how this fits into the evolution of Bitcoin addresses, see the address types comparison.

How It Works

P2SH transactions use a two-stage validation process. In the first stage, the network checks that the script provided by the spender hashes to the value committed in the output. In the second stage, the network executes that script to verify the spending conditions are met.

Creating a P2SH Output

To create a P2SH output, the recipient first constructs a redeem script containing the desired spending conditions. They then hash the redeem script using HASH160 (RIPEMD-160 of SHA-256) to produce a 20-byte digest. The resulting scriptPubKey is:

OP_HASH160 <20-byte-redeem-script-hash> OP_EQUAL

In raw hex, this is a914 followed by the 20-byte hash and 87, where a9 is OP_HASH160, 14 means "push 20 bytes," and 87 is OP_EQUAL. The sender constructs a transaction output paying to this scriptPubKey. From the sender's perspective, every P2SH payment looks identical: a 23-byte output script regardless of the underlying complexity.

Spending a P2SH Output

When the recipient spends the output, they provide a scriptSig containing:

1. The data needed to satisfy the redeem script (signatures, public keys, etc.)
2. The serialized redeem script itself as the final push

Validation proceeds in two stages:

1. Hash check: the network hashes the provided redeem script with HASH160 and compares it to the hash in the scriptPubKey. If they do not match, the transaction is invalid.
2. Script execution: the redeem script is deserialized and executed against the remaining stack data (the signatures and keys pushed before it). It must evaluate to true.

A critical rule: the scriptSig for P2SH inputs must contain only data push operations. No opcodes other than data pushes are allowed, which prevents certain script manipulation attacks.

Address Format

P2SH addresses use Base58Check encoding with version byte 0x05 on mainnet (0xC4 on testnet). This version byte causes all P2SH addresses to start with the digit "3." The encoding process:

1. Compute the HASH160 of the redeem script (20 bytes)
2. Prepend the version byte 0x05
3. Compute a checksum: the first 4 bytes of SHA-256(SHA-256(version + hash))
4. Append the checksum and encode the result as Base58

Base58 excludes visually ambiguous characters (0, O, I, l) to reduce transcription errors. The resulting address is approximately 34 characters long. Compare this to P2PKH addresses, which use version byte 0x00 and start with "1."

Example: 2-of-3 Multisig

The most common P2SH use case is multisig. For a 2-of-3 setup, the redeem script is:

# Redeem script
OP_2 <pubkey_A> <pubkey_B> <pubkey_C> OP_3 OP_CHECKMULTISIG

# ScriptPubKey (what goes on-chain)
OP_HASH160 <HASH160(redeem_script)> OP_EQUAL

# ScriptSig (to spend)
OP_0 <sig_A> <sig_B> <serialized_redeem_script>

The OP_0 at the start of the scriptSig is a dummy element required due to a long-standing off-by-one bug in OP_CHECKMULTISIG that pops one extra item from the stack. For more on how multisig wallets work in practice, see the multisig wallets guide.

Use Cases

Multisig Wallets

P2SH was originally designed to make multisig practical. Before BIP-16, sending to a multisig address required the sender to include the full m-of-n script in their output, making transactions large and expensive. P2SH allows the recipient to provide a single address regardless of the multisig configuration. Common configurations include 2-of-3 for cold storage and corporate treasury, and 3-of-5 for institutional custody.

With 33-byte compressed public keys, a P2SH multisig can accommodate a maximum of 15 keys due to the 520-byte script size limit, even though OP_CHECKMULTISIG itself supports up to 20.

Hash Time-Locked Contracts

HTLCs combine a hashlock (requiring a preimage to be revealed) with a timelock (allowing a refund after a deadline). P2SH wraps these conditions into a single address. HTLCs are the foundation of Lightning Network channels and enable atomic swaps across chains.

Timelocked Scripts

Using OP_CHECKLOCKTIMEVERIFY (BIP-65) and OP_CHECKSEQUENCEVERIFY (BIP-112), P2SH outputs can enforce time-based spending conditions. This enables inheritance planning (funds unlock after a specified block height), vesting schedules, and dispute resolution windows.

Nested SegWit (P2SH-P2WPKH)

During the SegWit rollout, many wallets and exchanges could not send to native bech32 addresses. P2SH-P2WPKH solves this by wrapping a SegWit witness program inside a P2SH output. The redeem script is simply OP_0 <20-byte-pubkey-hash>, and the resulting address starts with "3" like any other P2SH address.

This format provides roughly 24% fee savings compared to legacy P2PKH transactions thanks to the witness discount, though native SegWit (bech32) saves an additional 10% or more. As wallet support for native SegWit and Taproot has matured, nested SegWit is now considered a legacy compatibility format.

P2SH vs. P2WSH

P2WSH (Pay-to-Witness-Script-Hash), introduced with SegWit in 2017, improves on P2SH in three important ways:

For a 2-of-3 multisig input, P2SH costs approximately 296 virtual bytes compared to roughly 104 vBytes for P2WSH: a 65% reduction that translates directly to lower transaction fees. For complex scripts that benefit from Miniscript composition, P2WSH's 10,000-byte limit removes practical constraints that P2SH's 520-byte ceiling imposes.

Why It Matters

P2SH was a pivotal upgrade for Bitcoin's programmability. By decoupling the spending conditions from the output, it made Bitcoin Script practical for real-world use. Before P2SH, senders needed to understand and construct complex scripts themselves. After P2SH, they only need a standard address.

The pattern P2SH established: committing to a hash on-chain and revealing the full data only when spending: became foundational for Bitcoin's evolution. SegWit extended this pattern with witness programs, and Taproot took it further with Merkle-ized script trees that reveal only the executed branch. Each step built on the principle P2SH introduced: hide complexity until it matters.

Today, P2SH addresses still hold an estimated 24% of all Bitcoin supply, though much of this is actually nested SegWit (P2SH-P2WPKH and P2SH-P2WSH), which is indistinguishable from regular P2SH on-chain. Layer-2 protocols like Spark and the Lightning Network continue to rely on script-hash patterns that trace directly back to P2SH's design, using hashed spending conditions to enable off-chain transactions with on-chain security guarantees.

Risks and Considerations

Collision Vulnerability

P2SH's HASH160 produces a 160-bit digest, giving it birthday-attack collision resistance of only 2^80 operations. In a multisig context, a malicious co-signer could theoretically find a collision between a legitimate multisig redeem script and a script that pays solely to themselves. While no such attack has been demonstrated in practice, the Bitcoin mining network has performed well over 2^84 cumulative hash operations since genesis, demonstrating that 2^80 work is within reach of a well-resourced attacker. P2WSH addresses this by using 256-bit SHA-256 with 2^128 collision resistance.

Script Size Limitations

The 520-byte redeem script limit constrains what P2SH can express. A 15-of-15 multisig just barely fits (approximately 513 bytes with compressed keys), and more complex scripts like tiered spending policies or large Miniscript compositions may not fit at all. P2WSH removes this bottleneck with its 10,000-byte consensus limit.

No Witness Discount

Pure P2SH transactions do not benefit from SegWit's witness discount. The signatures and redeem script in the scriptSig count at full weight (4 weight units per byte), making P2SH transactions significantly more expensive per input than their P2WSH equivalents. For applications processing many UTXOs, this cost difference compounds quickly.

Privacy Tradeoffs

P2SH hides the spending conditions until the output is spent, which is better than bare multisig where conditions are visible immediately. However, once spent, the full redeem script is revealed on-chain, exposing the multisig configuration or other script logic. Taproot improves on this by revealing only the spending path that was actually used, keeping alternative conditions private.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.