P2PKH (Pay-to-Public-Key-Hash)

What Is P2PKH?

P2PKH (Pay-to-Public-Key-Hash) is a Bitcoin transaction output type that locks funds to the hash of a recipient's public key. To spend the funds, the recipient must provide both the original public key and a valid ECDSA signature. This was the first standardized address format in Bitcoin and remains the most widely recognized: any address starting with "1" is a P2PKH address.

P2PKH replaced the earlier P2PK (Pay-to-Public-Key) format, which embedded the full public key directly in the transaction output. By hashing the public key, P2PKH achieves two things: it reduces the on-chain footprint from 33 bytes (compressed public key) to 20 bytes (HASH160 digest), and it conceals the public key until the moment of spending. This design was intentional: Satoshi recognized that hiding the public key behind a hash provided an additional cryptographic barrier, particularly relevant if elliptic curve cryptography were ever weakened.

For a comprehensive comparison of all Bitcoin address formats, see the research article on Bitcoin address types from P2PKH to Taproot.

How It Works

Every P2PKH transaction involves two scripts that work together: a locking script (scriptPubKey) placed on the output, and an unlocking script (scriptSig) provided by the spender. The Bitcoin network concatenates and executes these scripts to verify that the spender controls the private key associated with the address.

The Locking Script (scriptPubKey)

When someone sends bitcoin to a P2PKH address, the transaction output contains this Bitcoin Script:

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

The <pubKeyHash> is a 20-byte value produced by applying SHA-256 followed by RIPEMD-160 (collectively called HASH160) to the recipient's public key. In raw hex, the full scriptPubKey is 25 bytes:

76 a9 14 <20-byte-pubkey-hash> 88 ac

76    = OP_DUP
a9    = OP_HASH160
14    = Push next 20 bytes
[20B] = HASH160 of the public key
88    = OP_EQUALVERIFY
ac    = OP_CHECKSIG

The Unlocking Script (scriptSig)

To spend a P2PKH output, the owner provides their signature and public key:

<signature> <publicKey>

The signature is a DER-encoded ECDSA signature (typically 71 to 72 bytes), and the public key is 33 bytes when compressed. Together with length prefixes, the scriptSig totals approximately 107 bytes.

Script Execution

When a node validates a P2PKH spend, it executes the combined script step by step on a stack:

1. Push <signature> and <publicKey> from the scriptSig onto the stack
2. OP_DUP duplicates the public key on top of the stack
3. OP_HASH160 pops the duplicate and pushes its HASH160 (SHA-256 then RIPEMD-160)
4. The 20-byte <pubKeyHash> from the scriptPubKey is pushed onto the stack
5. OP_EQUALVERIFY compares the two hashes: if they do not match, the script fails immediately
6. OP_CHECKSIG verifies the signature against the original public key: if valid, the spend is authorized

This two-step verification ensures that the spender both knows the public key that hashes to the address and controls the corresponding private key. For a deeper look at how Bitcoin scripts are evaluated, see the research article on Bitcoin Script programmability.

Address Encoding

P2PKH addresses use Base58Check encoding, which converts the raw bytes into a human-readable string while adding error detection:

1. Start with the 20-byte HASH160 of the public key
2. Prepend a version byte: 0x00 for mainnet, 0x6f for testnet
3. Compute a 4-byte checksum: the first four bytes of SHA-256(SHA-256(version + payload))
4. Append the checksum to the versioned payload
5. Encode the result using the Base58 alphabet, which excludes visually ambiguous characters (0, O, l, I) to reduce transcription errors

The result is an address 26 to 34 characters long, always starting with "1" on mainnet. For example: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa (the genesis block coinbase address).

P2PKH vs Modern Address Types

P2PKH was the standard for Bitcoin's first eight years, but newer formats have largely superseded it. The key differences come down to transaction weight, fee efficiency, and features:

The SegWit upgrade (activated in August 2017) introduced the witness discount, which counts signature data at one-quarter weight. Since P2PKH places all signature and public key data in the scriptSig rather than the witness field, it receives no discount: every byte counts at full weight. This makes P2PKH transactions significantly more expensive in fees for the same economic activity.

Taproot (activated in November 2021) went further by introducing Schnorr signatures, which are smaller (64 bytes vs ~72 bytes for ECDSA) and enable batch verification. Taproot also makes single-sig, multisig, and complex script spends look identical on-chain, providing a privacy benefit that P2PKH cannot offer.

Why It Matters

Despite being a legacy format, P2PKH remains relevant for several reasons. Approximately 43% of all mined bitcoin is still held in P2PKH addresses, largely by early adopters and long-term holders. Any wallet, exchange, or service that handles Bitcoin must support P2PKH to interact with these funds.

Understanding P2PKH is also foundational for grasping how Bitcoin's UTXO model works. Each P2PKH output is a discrete, spendable coin locked by a script: this is the UTXO paradigm in its simplest form. More advanced constructions like P2SH, P2WPKH, and Taproot all build on the same script-based locking model that P2PKH established.

For developers building Bitcoin applications, P2PKH provides the clearest illustration of how Bitcoin Script evaluation works. The five-opcode pattern is simple enough to trace by hand, yet it demonstrates the fundamental concepts of stack-based execution, hash verification, and signature checking that underpin all Bitcoin transactions.

Modern Bitcoin infrastructure like Spark builds on top of these primitives to enable faster, cheaper transactions while preserving the self-custodial security model that P2PKH originally introduced.

Use Cases

• Legacy wallet compatibility: older wallets and hardware devices that predate SegWit generate P2PKH addresses by default. The derivation path m/44'/0'/0' (defined in BIP-44) is specifically designated for P2PKH addresses.
• Maximum compatibility: P2PKH addresses are universally supported. Every Bitcoin wallet, exchange, and service can send to and receive from a "1" address. When interoperability is the priority, P2PKH remains the safest choice.
• Long-term cold storage: many cold storage setups created before 2017 use P2PKH. Moving these funds to newer address types requires an on-chain transaction (and fees), so holders often leave them in place.
• Educational purposes: the straightforward script pattern makes P2PKH the standard teaching example for Bitcoin transaction mechanics, Bitcoin Script execution, and the UTXO model.

Risks and Considerations

Higher Transaction Fees

P2PKH transactions are the most expensive standard transaction type. A typical single-input P2PKH transaction uses ~226 vbytes compared to ~141 vbytes for P2WPKH. During periods of high network congestion, this difference can translate to fees that are 40% or more above what SegWit users pay. For frequent transactors, the cumulative cost is substantial.

Public Key Exposure on Spend

While P2PKH conceals the public key for unspent outputs, spending reveals it in the scriptSig. If an address is reused (receiving multiple payments), the public key becomes permanently visible on-chain after the first spend. This reduces the quantum resistance benefit and slightly degrades privacy. Best practice is to use each P2PKH address only once, which HD wallets handle automatically by generating fresh addresses for each transaction.

Quantum Computing Considerations

P2PKH provides partial protection against quantum attacks: an unspent output reveals only the hash, not the public key. A quantum computer running Shor's algorithm could theoretically derive a private key from a public key but cannot reverse the HASH160 function. However, this protection only holds for unspent, never-reused addresses. Once spent, the public key is exposed, and any remaining funds at that address (from address reuse) lose this protection. For a detailed analysis of this threat, see the glossary entry on Shor's algorithm vulnerability.

Declining Ecosystem Support

Some newer wallets and services default to SegWit or Taproot addresses and may eventually deprecate P2PKH support for sending. While receiving support is unlikely to be removed (backward compatibility is a core Bitcoin principle), users relying exclusively on P2PKH addresses may face friction as the ecosystem moves toward BIP-84 (P2WPKH) and BIP-86 (P2TR) as defaults.

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.