P2SH (Pay-to-Script-Hash)

What Is P2SH (Pay-to-Script-Hash)?

P2SH (Pay-to-Script-Hash) is a Bitcoin transaction output type that lets someone send bitcoin to the hash of a script instead of sending directly to a public key or public key hash.

The sender only needs a short script hash, while the spender later reveals the full script and provides the data needed to satisfy it.

In simple terms, P2SH lets a Bitcoin address represent complex spending rules without forcing the sender to understand those rules.

A P2SH address on Bitcoin mainnet commonly starts with the number

.

The technical standard for P2SH was introduced in BIP16.

The address format for P2SH was described in BIP13.

P2SH became important because it made advanced Bitcoin scripts easier to use in normal wallet payments.

Before P2SH, a sender who wanted to pay into a complex script needed to place that complex script directly in the transaction output.

That was inefficient, hard to share, and difficult for ordinary wallets to support.

With P2SH, the sender can pay to a compact hash, and the receiver takes responsibility for revealing and satisfying the full script when spending.

This design made multisignature wallets, escrow-style transactions, and later nested SegWit compatibility much more practical.

For crypto users, P2SH is best understood as a Bitcoin address and script design that hides complexity at the receiving stage and reveals it only when the funds are spent.

Key Takeaways About P2SH

• • P2SH stands for Pay-to-Script-Hash.
  • It lets bitcoin be locked to the hash of a script instead of a normal public key hash.
  • Mainnet P2SH addresses usually start with
    3
    .
  • The sender does not need to know the full spending script.
  • The spender must reveal the redeem script and satisfy its conditions when spending.
  • P2SH was standardized through BIP16 and its address format was described in BIP13.
  • P2SH helped make multisignature wallets easier to use.
  • P2SH was also used as a compatibility wrapper for early SegWit adoption.
  • Modern Bitcoin users may prefer native SegWit or Taproot address types when supported.

Why P2SH Was Created

P2SH was created to make complex Bitcoin scripts easier to receive and pay.

Bitcoin Script allows coins to be locked with spending conditions.

A simple payment might require one valid signature from one private key.

A more complex payment might require two signatures out of three keys, a time lock, or other script logic.

Before P2SH, the sender had to include the full script in the transaction output if they wanted to pay into those conditions.

This pushed complexity onto the sender, even though the receiver was the party choosing the security rules.

BIP16 states that the purpose of P2SH is to move responsibility for supplying redemption conditions from the sender to the redeemer.

This design is useful because the sender only needs to pay to a short script hash.

The receiver can then manage the actual script privately until the funds are spent.

This makes the payment experience simpler for wallets and users.

It also reduces the need for senders to support every possible custom script before they can pay someone.

The sender can treat a P2SH address much like a normal address, while the receiver can use advanced spending rules behind it.

How P2SH Works

P2SH works by locking bitcoin to a hash of a script.

That hidden script is called the redeem script.

The redeem script defines the real conditions that must be satisfied to spend the coins.

The transaction output does not contain the full redeem script.

Instead, it contains a hash of that redeem script.

When the coins are later spent, the spender provides the redeem script and the required unlocking data.

The Bitcoin network checks that the redeem script hashes to the same script hash used in the original output.

Then the network checks that the unlocking data satisfies the redeem script.

If both checks pass, the spend is valid.

If the provided script does not match the hash, the spend fails.

If the script matches but the signatures or other conditions fail, the spend also fails.

This two-step process is the core idea behind Pay-to-Script-Hash.

The Basic P2SH Script Pattern

A standard P2SH locking script has a simple pattern.

It is commonly written as

.

This means the spending transaction must provide a script whose

value matches the 20-byte script hash in the output.

The Bitcoin.org developer guide explains that P2SH is used to send a transaction to a script hash.

The unlocking script provides the data needed by the redeem script.

It also provides the redeem script itself.

A common conceptual form is

.

The exact unlocking data depends on what the redeem script requires.

For a multisignature redeem script, the unlocking data may include multiple signatures.

For a time-locked script, the transaction must also satisfy the locktime rules.

The script hash keeps the output compact, while the redeem script keeps the spending logic flexible.

What Is a Redeem Script?

A redeem script is the hidden script behind a P2SH address.

It defines the actual spending rules for the coins locked to that address.

For example, a redeem script could say that two out of three specified public keys must provide valid signatures.

That would create a 2-of-3 multisignature setup.

The P2SH address does not show this full script before the funds are spent.

It only represents the hash of the redeem script.

When spending, the user reveals the redeem script and proves that it matches the hash.

The user must also provide whatever signatures, public keys, or data the redeem script requires.

This makes the redeem script the real security policy of the P2SH output.

If the redeem script is lost, the funds may become unspendable.

If the redeem script is wrong, the funds may be locked to rules the user cannot satisfy.

A P2SH wallet must therefore back up not only private keys but also the scripts needed to spend.

P2SH Address Format

P2SH introduced a new Bitcoin address format so users could share script-hash payment destinations more easily.

BIP13 describes an address format for pay-to-script-hash where the address represents the encoded hash of a script rather than the encoded hash of a public key.

On Bitcoin mainnet, a P2SH address usually starts with

.

This makes it visually different from older P2PKH addresses, which usually start with

.

However, users should never rely only on the first character of an address for safety.

They should still copy and verify the full address carefully.

A P2SH address is normally a Base58Check-encoded form of the script hash with a version byte.

The Bitcoin.org transaction reference notes that P2SH addresses use version byte

in the common address encoding process.

This address format made complex scripts easier to share through wallet interfaces, QR codes, invoices, and payment requests.

Without an address format, complex scripts would have been much harder for ordinary users to send to safely.

P2SH and Multisignature Wallets

P2SH is famous because it made multisignature wallets easier to use.

A multisignature wallet requires more than one private key to spend funds.

A 2-of-3 multisig wallet, for example, can spend funds when any two of three approved keys sign.

This is useful for businesses, families, treasury accounts, escrow arrangements, and personal cold storage.

Without P2SH, sending to a multisig script required the sender to include the full multisig script in the output.

With P2SH, the sender only sends to a short P2SH address.

The receiver’s wallet handles the multisig redeem script when spending later.

This made multisig practical for normal payment flows.

It also made wallet interfaces simpler because a multisig address could look like one ordinary address to the sender.

The sender does not need to know whether the recipient uses one key, multiple keys, or a more complex setup.

The recipient can improve security without making the sender’s experience more complicated.

P2SH vs P2PKH

P2PKH stands for Pay-to-Public-Key-Hash.

It is the classic Bitcoin payment type where funds are locked to the hash of a public key.

To spend a P2PKH output, the spender provides a public key and a valid signature from the matching private key.

P2SH is different because funds are locked to the hash of a script.

That script can require one signature, multiple signatures, a time condition, or other allowed Bitcoin Script logic.

P2PKH is simpler.

P2SH is more flexible.

A P2PKH address usually starts with

on Bitcoin mainnet.

A P2SH address usually starts with

on Bitcoin mainnet.

P2PKH is easy for basic payments.

P2SH is useful when the recipient wants more complex spending rules without exposing those rules to the sender at payment time.

P2SH vs Bare Multisig

Bare multisig means placing a multisignature script directly in a transaction output.

This was possible in Bitcoin before P2SH became widely used.

However, bare multisig made outputs larger and forced the sender to handle the full script.

P2SH improved this by replacing the full output script with a compact script hash.

The full multisig script is revealed only when the funds are spent.

This shifts data from the funding transaction to the spending transaction.

That is more convenient because the recipient is the one choosing and later satisfying the spending policy.

For users, the practical result was simple.

They could receive bitcoin to a multisig setup using a normal-looking address.

This helped multisig become a common security tool for Bitcoin custody.

P2SH and SegWit

P2SH became important again during the adoption of SegWit.

SegWit, defined in BIP141, introduced witness data and new output types such as P2WPKH and P2WSH.

Early SegWit adoption faced a compatibility problem.

Some wallets and services could not immediately send to native SegWit addresses.

P2SH provided a bridge.

A SegWit script could be wrapped inside a P2SH address, allowing older sending wallets to pay to an address starting with

.

The receiving wallet could later spend using SegWit rules.

Bitcoin Core’s Segregated Witness wallet development guide says SegWit-compatible wallets must support P2SH and its BIP13 address format.

This made P2SH a major transition tool for Bitcoin wallet compatibility.

Nested SegWit is less efficient than native SegWit, but it helped users and services adopt SegWit gradually.

P2SH-P2WPKH

P2SH-P2WPKH means Pay-to-Witness-Public-Key-Hash wrapped inside P2SH.

It is often called nested SegWit.

The address looks like a P2SH address because it starts with

.

However, the redeem script is actually a SegWit witness program.

This allows older systems that understand P2SH but not native SegWit addresses to send funds to a SegWit-capable wallet.

BIP49 defines a derivation scheme for P2WPKH nested in P2SH for hierarchical deterministic wallets.

This helped wallets organize nested SegWit accounts in a standardized way.

P2SH-P2WPKH was especially useful during the transition period when native SegWit support was not universal.

Today, many wallets can send to native SegWit addresses directly.

When native SegWit is supported, it is usually more efficient than nested SegWit.

P2SH-P2WSH

P2SH-P2WSH means Pay-to-Witness-Script-Hash wrapped inside P2SH.

It is similar in spirit to P2SH-P2WPKH, but it supports more complex witness scripts.

A P2WSH script can represent advanced conditions such as multisignature policies in the SegWit witness structure.

Wrapping it in P2SH allowed older sending wallets to pay to those scripts using a familiar

-starting address.

This was useful for compatibility, but it added some overhead compared with native P2WSH.

As native SegWit and newer address formats became more widely supported, the need for P2SH wrapping decreased.

Still, P2SH-P2WSH remains important for understanding Bitcoin’s upgrade path.

Bitcoin often adopts new features in ways that preserve compatibility with older wallet infrastructure.

P2SH helped make that kind of gradual upgrade possible.

P2SH vs P2WSH

P2SH and P2WSH both allow funds to be locked to script hashes, but they are not the same.

P2SH is the older script-hash design from BIP16.

P2WSH is the SegWit version that places script and signature data in the witness structure.

P2WSH can be more efficient for many complex scripts because witness data is discounted under Bitcoin’s weight rules.

P2WSH also benefits from SegWit’s transaction structure changes.

P2SH remains important because of legacy compatibility and historical adoption.

A P2SH address starts with

.

A native SegWit P2WSH address usually starts with

on Bitcoin mainnet.

When both sender and receiver support native SegWit, P2WSH is generally preferred for complex scripts.

When compatibility with older systems is needed, P2SH wrapping may still appear.

P2SH vs Taproot

Taproot is a newer Bitcoin output type that can improve privacy and efficiency for some spending policies.

Taproot outputs are not the same as P2SH outputs.

P2SH reveals the full redeem script when spending, even if only one branch of logic is used.

Taproot can allow some complex policies to look like a simple key-path spend when cooperative conditions are met.

This can improve privacy because observers may not see the unused script conditions.

Taproot can also make some advanced wallet policies more efficient.

However, P2SH is still important because it remains part of Bitcoin’s history, wallet compatibility, and existing coin set.

Many old addresses and outputs still use P2SH.

Users should not assume all

-starting addresses are outdated or unsafe.

They should understand the specific wallet type and spending policy involved.

Fees and Transaction Size

P2SH can affect transaction fees because script data is revealed when spending.

A simple P2SH spend may be relatively small.

A complex multisig P2SH spend can be larger because it must include the redeem script and multiple signatures.

Bitcoin fees are based on transaction weight or size, depending on the context and transaction type.

Larger spends generally cost more when fee rates are high.

This is one reason native SegWit and Taproot became attractive for some use cases.

They can reduce cost or improve efficiency for certain spending patterns.

Still, P2SH was a major improvement over placing complex scripts directly in the output.

It made the funding transaction compact and moved complexity to the spending side.

Users should check wallet fee estimates before spending from complex P2SH wallets, especially multisig wallets.

Privacy Characteristics of P2SH

P2SH hides the redeem script until the coins are spent.

This means observers cannot see the full spending policy at the time the coins are received.

They can only see the script hash.

When the coins are spent, the redeem script becomes visible on-chain.

At that point, observers can often identify whether the output used multisig, nested SegWit, or another script pattern.

This creates partial privacy, not complete privacy.

P2SH can hide complexity before spending, but it does not hide the script forever.

Also, the address format itself can reveal that the output is P2SH.

Chain analysis may still identify wallet behavior, address reuse, spending patterns, and transaction relationships.

Users should not treat P2SH as a privacy solution by itself.

Security Benefits of P2SH

The first major security benefit of P2SH is that it made multisignature custody easier to receive.

Multisig can reduce single-key theft risk because an attacker may need more than one key to spend funds.

The second benefit is that P2SH reduces the sender’s need to handle complex scripts.

This lowers the chance that a sender creates the wrong output script by mistake.

The third benefit is that P2SH allows recipients to choose their own security policy.

A business can use multisig without asking every customer to understand its internal wallet setup.

The fourth benefit is upgrade flexibility.

P2SH helped support nested SegWit adoption when native SegWit sending support was still uneven.

The fifth benefit is script-hash compactness.

A short hash is easier to encode into an address than a full redeem script.

These benefits made P2SH one of the most important usability improvements in Bitcoin scripting history.

Security Risks of P2SH

The first major risk is losing the redeem script.

If a user has the private keys but not the script needed to spend, the funds may be inaccessible.

This is especially important for multisig wallets.

The second risk is creating the wrong redeem script.

If funds are sent to a hash of a script that no one can satisfy, the funds can be permanently locked.

The third risk is misunderstanding address types.

An address starting with

may be legacy P2SH multisig, nested SegWit, or another valid P2SH construction.

The fourth risk is relying on outdated wallet backups.

A backup must include enough information to reconstruct the spending policy, not only private keys.

The fifth risk is high spending cost during fee spikes.

Complex P2SH scripts can create larger spending transactions.

The sixth risk is script exposure at spend time.

Once the redeem script is revealed, observers can learn more about the wallet policy.

P2SH is powerful, but it requires careful wallet design and backup discipline.

P2SH and Wallet Backups

P2SH wallets can require more careful backup practices than simple single-key wallets.

For a simple P2PKH wallet, backing up the seed phrase may be enough if the wallet follows standard derivation paths.

For a P2SH multisig wallet, the user may need the seed phrases, public keys, derivation paths, wallet policy, and redeem script information.

If part of this information is missing, recovery can be difficult.

Modern multisig wallets often export wallet descriptors or configuration files to solve this problem.

A descriptor can describe how addresses and scripts are generated.

Without that information, the user may not know which keys and scripts control the funds.

This is one reason multisig users should test recovery before depositing large amounts.

A P2SH address can look simple, but the wallet policy behind it may be complex.

Good backups must preserve that complexity in a recoverable way.

P2SH and Developers

Developers working with P2SH need to understand both address encoding and script validation.

They must create the redeem script correctly.

They must hash the redeem script correctly.

They must encode the address correctly.

They must build spending transactions that provide the right unlocking data and redeem script.

They must test edge cases such as multisig ordering, signature encoding, dust limits, fee estimation, transaction weight, and wallet recovery.

They must also distinguish between legacy P2SH and nested SegWit P2SH.

Those two can look similar to users because both use addresses starting with

, but the spending structure differs.

Developers should rely on well-reviewed Bitcoin libraries rather than inventing their own script handling.

Bitcoin Script is simple in appearance but unforgiving in practice.

A small mistake in a redeem script can make funds unspendable.

P2SH and Users

Most users do not need to build P2SH scripts manually.

They encounter P2SH through wallet addresses, multisig vaults, custody setups, or older SegWit-compatible wallets.

If a wallet gives a user an address starting with

, it may be a P2SH address.

The user should still rely on the wallet’s explanation rather than guessing from the first character alone.

When receiving bitcoin, users should copy the full address carefully or use a trusted QR code.

When sending bitcoin, users should confirm that the receiving address belongs to the intended recipient.

When using multisig, users should keep all required backup information in secure locations.

When using old wallets, users should understand whether funds are stored in legacy P2SH, nested SegWit, native SegWit, or Taproot outputs.

Address type affects fee estimates, compatibility, privacy, and recovery.

A good wallet should hide unnecessary complexity while still giving the user enough information to avoid costly mistakes.

Common Use Cases for P2SH

The most famous use case for P2SH is multisignature custody.

A family, company, or treasury can require several keys before funds are moved.

Another use case is escrow.

A script can require signatures from agreed parties under specific conditions.

Another use case is legacy-compatible SegWit receiving.

A wallet can use P2SH wrapping so older senders can pay into a SegWit-capable wallet.

Another use case is script-based access control.

Coins can be locked to script rules that are more advanced than one key and one signature.

Another use case is historical wallet recovery.

Many older Bitcoin wallets and addresses used P2SH, so understanding it is important when recovering old funds.

P2SH remains part of Bitcoin’s active transaction history even as newer output types become more common.

Common Misunderstandings About P2SH

One common misunderstanding is that every address starting with

is a multisig address.

That is not always true because nested SegWit outputs can also use P2SH addresses.

Another misunderstanding is that P2SH hides the spending script forever.

It does not because the redeem script is revealed when the output is spent.

A third misunderstanding is that P2SH makes scripts safer automatically.

It does not because a bad redeem script can still lock funds permanently.

A fourth misunderstanding is that the sender needs to understand the recipient’s script.

The sender only needs the P2SH address.

A fifth misunderstanding is that private keys alone always recover P2SH funds.

For multisig and custom scripts, the redeem script or wallet policy may also be required.

A sixth misunderstanding is that P2SH is obsolete in every context.

Newer address types may be more efficient, but P2SH remains relevant for compatibility and historical funds.

Best Practices for P2SH

Use trusted wallet software that handles P2SH scripts correctly.

Do not manually create redeem scripts unless you understand Bitcoin Script deeply.

Back up all required wallet policy data, not only seed phrases.

For multisig wallets, store cosigner information and derivation paths safely.

Test recovery with small amounts before using large balances.

Prefer native SegWit or Taproot when they are supported and appropriate for the use case.

Use P2SH compatibility only when it solves a real wallet support problem.

Verify the full address before sending funds.

Avoid address reuse when privacy matters.

Check fee estimates before spending from complex P2SH outputs.

Keep wallet software updated so it can properly recognize and spend older P2SH outputs.

Understand the difference between legacy P2SH multisig and nested SegWit P2SH addresses.

P2SH in One Sentence

P2SH (Pay-to-Script-Hash) is a Bitcoin output type that locks coins to the hash of a redeem script so the sender can pay a simple address while the spender later reveals and satisfies the full script.

FAQ

What does P2SH stand for?

P2SH stands for Pay-to-Script-Hash.

What is P2SH used for?

P2SH is used to lock bitcoin to the hash of a script, making complex spending rules easier to receive through a normal-looking address.

What does a P2SH address start with?

A Bitcoin mainnet P2SH address usually starts with

.

Who introduced P2SH?

P2SH was standardized through BIP16, which was authored by Gavin Andresen.

What is the purpose of P2SH?

The purpose is to move the responsibility for providing complex spending conditions from the sender to the spender.

What is a redeem script?

A redeem script is the full script that defines how coins locked to a P2SH output can be spent.

Does the sender need to know the redeem script?

No, the sender only needs the P2SH address that represents the script hash.

When is the redeem script revealed?

The redeem script is revealed when the P2SH output is spent.

Is P2SH the same as multisig?

No, P2SH is not the same as multisig, but it is often used to make multisig wallets easier to receive payments.

Is every address starting with 3 a multisig address?

No, an address starting with

may be multisig, nested SegWit, or another P2SH construction.

Is P2SH still used today?

Yes, P2SH still appears in Bitcoin transactions, especially for compatibility and older wallets, although many users now prefer native SegWit or Taproot when supported.

What is the biggest P2SH risk?

The biggest risk is losing or misconstructing the redeem script or wallet policy, which can make funds impossible to spend.

Conclusion

P2SH (Pay-to-Script-Hash) is one of the most important upgrades in Bitcoin’s scripting history.

It made complex spending rules practical by allowing users to receive bitcoin through a compact script-hash address.

The sender does not need to understand the full script.

The spender reveals and satisfies the redeem script only when spending.

This design made multisignature wallets easier to use and helped Bitcoin support stronger custody models.

It also helped Bitcoin transition into SegWit through nested SegWit address formats.

P2SH is not the newest or most efficient Bitcoin output type in every case.

Native SegWit and Taproot can offer advantages in fees, privacy, and script design when supported.

However, P2SH remains important because it shaped how Bitcoin wallets handle advanced scripts and because many existing outputs still use it.

For users, the main lesson is that a simple address can hide a complex spending policy.

For developers, the main lesson is that script correctness, backups, and wallet recovery data are critical.

For the Bitcoin ecosystem, P2SH showed how a protocol upgrade can improve usability while preserving decentralization and compatibility.

Understanding P2SH helps users understand multisig, nested SegWit, script hashes, redeem scripts, and the careful design philosophy behind Bitcoin upgrades.