What is the difference between P2PKH and P2SH for wallet addresses?

P2PKH addresses start with "1" and require a public key and signature to spend funds, while P2SH addresses begin with "3" and allow complex spending conditions like multisignature setups.

Jun 15, 2025 at 03:35 pm

Understanding P2PKH and P2SH in Bitcoin Transactions

When interacting with Bitcoin wallets, users often encounter different types of addresses. Two of the most common are P2PKH (Pay-to-Public-Key-Hash) and P2SH (Pay-to-Script-Hash). These terms refer to the underlying transaction scripts that dictate how funds can be spent. Understanding their differences is essential for anyone working with Bitcoin transactions, especially developers, wallet providers, and advanced users.

---

What Is P2PKH?

P2PKH (Pay-to-Public-Key-Hash) is the original and most basic type of Bitcoin address. It starts with the number "1" and was introduced in the early versions of Bitcoin. When sending funds to a P2PKH address, the sender specifies that the recipient must provide both a valid public key and a digital signature matching the hash embedded in the script.

To break it down:

• The recipient's public key is hashed twice—first with SHA-256, then with RIPEMD-160—to create a shorter, secure identifier.
• This hash is encoded using Base58Check to produce the familiar "1..." format.
• When spending from a P2PKH output, the user must reveal their public key and provide a signature proving ownership.

This method ensures simplicity and widespread compatibility across older systems.

---

What Is P2SH?

P2SH (Pay-to-Script-Hash) introduces more flexibility into Bitcoin transactions. Introduced via BIP 16, this type of address typically starts with "3". Instead of locking funds to a public key hash, P2SH locks them to the hash of a script. This means that the actual conditions required to spend the coins are hidden until redemption time.

Here’s how it works:

• A complex script is created by the recipient or wallet provider. This could include multisignature logic, timelocks, or other custom conditions.
• The hash of this script is encoded into a P2SH address.
• When someone sends funds to this address, they only know the hash—not the full details of the redemption conditions.
• Upon spending, the redeemer provides both the original script and any data required to satisfy its conditions (like multiple signatures).

This model enhances privacy and allows for advanced smart contract-like features on Bitcoin without exposing complexity upfront.

---

Key Differences Between P2PKH and P2SH

While both P2PKH and P2SH are used to send and receive Bitcoin, they differ significantly in structure and use cases:

• Address Format:

  • P2PKH addresses start with “1” due to version byte encoding.
  • P2SH addresses begin with “3”.

• Redemption Logic:

  • In P2PKH, the spender reveals the public key and signature during redemption.
  • In P2SH, the spender reveals the original script and data satisfying its conditions at the time of spending.

• Complexity and Flexibility:

  • P2PKH supports only simple single-signature transactions.
  • P2SH enables complex conditions like multisig, m-of-n thresholds, and custom logic.

• Privacy and On-chain Footprint:

  • P2PKH exposes public keys immediately upon spending.
  • P2SH hides the full script until redemption, reducing on-chain visibility of complex logic.

These distinctions make each suitable for different scenarios, such as everyday transactions versus collaborative fund management.

---

How Are These Addresses Generated?

Creating P2PKH and P2SH addresses involves cryptographic operations and encoding steps. Below is a simplified breakdown:

For P2PKH Address Generation:

• Generate a private key using ECDSA.
• Derive the corresponding public key.
• Apply SHA-256 followed by RIPEMD-160 to obtain the public key hash.
• Prepend the network byte (e.g., 0x00 for mainnet).
• Perform double SHA-256 checksum and append first 4 bytes.
• Encode the result using Base58Check to get the final address.

For P2SH Address Generation:

• Create a redeem script (e.g., multisig).
• Hash the script with SHA-256 and RIPEMD-160.
• Add the P2SH version byte (e.g., 0x05 for mainnet).
• Compute the double SHA-256 checksum.
• Use Base58Check encoding to form the final address.

Each step plays a crucial role in ensuring security and interoperability within the Bitcoin ecosystem.

---

Use Cases for Each Type

The choice between P2PKH and P2SH depends heavily on the intended use case:

• P2PKH is ideal for straightforward peer-to-peer transactions where simplicity and wide support are priorities. Most early wallets and exchanges default to P2PKH addresses.

• P2SH shines in environments requiring additional security layers or cooperative control. Common applications include:

  • Multisignature wallets where multiple parties must approve a transaction.
  • Escrow services where funds are released after certain conditions are met.
  • Time-locked contracts that delay fund availability until a future block height or timestamp.

By abstracting complex logic behind a hash, P2SH improves usability while maintaining the integrity of Bitcoin’s scripting system.

---

Frequently Asked Questions

Q: Can I convert a P2PKH address to a P2SH address?

No, you cannot directly convert one type of address to another. However, you can create a new P2SH address using a custom script and transfer funds from your P2PKH address to it.

Q: Which address type offers better privacy?
P2SH generally offers better privacy because the underlying script logic remains hidden until the transaction is spent. In contrast, P2PKH exposes the public key when funds are moved.

Q: Are P2SH addresses compatible with all Bitcoin wallets?

Most modern wallets support P2SH addresses, especially those implementing BIP 16. However, some legacy systems may not recognize them or require manual configuration.

Q: Why do P2SH addresses start with "3"?

This is due to the version byte used during encoding. For P2SH addresses on the Bitcoin mainnet, the version byte is set to 0x05, which results in the "3" prefix when encoded with Base58Check.