P2PK (Pay-to-Public-Key)

What Is P2PK?

P2PK (Pay-to-Public-Key) is a Bitcoin output script pattern that locks funds directly to a recipient's public key. To spend the coins, the owner simply provides a valid digital signature corresponding to that key. No address, no hash: just a raw public key embedded in the locking script on the blockchain.

Satoshi Nakamoto used P2PK for every coinbase transaction in Bitcoin's earliest blocks, including the famous genesis block mined on January 3, 2009. The first peer-to-peer Bitcoin transfer: Satoshi sending 10 BTC to Hal Finney in block 170: was also a P2PK transaction. At the time, there was no concept of a Bitcoin address. Users exchanged raw public keys directly, and P2PK was the only way to receive bitcoin.

As the network matured, P2PK was superseded by P2PKH (Pay-to-Public-Key-Hash), which hashes the public key before embedding it in the script. Every modern script type: P2SH, P2WPKH, P2WSH, and P2TR (Taproot): uses some form of hashing or key tweaking rather than exposing the raw public key in the output.

How It Works

P2PK is the simplest possible spending condition in Bitcoin Script. It involves just two opcodes: a push of the public key data and OP_CHECKSIG.

Locking Script (scriptPubKey)

The locking script embeds the full public key and requires a valid signature to spend:

<pubkey> OP_CHECKSIG

The public key can be either an uncompressed key (65 bytes, starting with 0x04) or a compressed key (33 bytes, starting with 0x02 or 0x03). Early Bitcoin transactions used uncompressed keys exclusively. Compressed keys were adopted later to save block space.

Unlocking Script (scriptSig)

To spend a P2PK output, the owner provides only a signature:

<signature>

Script Execution

The Bitcoin Script interpreter concatenates the unlocking and locking scripts and evaluates them together:

// Combined script
<signature> <pubkey> OP_CHECKSIG

// Execution steps:
// 1. Push <signature> onto the stack
// 2. Push <pubkey> onto the stack
// 3. OP_CHECKSIG pops both values, verifies the
//    signature against the pubkey and the transaction
//    data, and pushes TRUE (1) if valid

If OP_CHECKSIG returns TRUE, the transaction is valid and the coins can be spent. If the signature does not match the public key, the script fails and the spend is rejected.

Comparison with P2PKH

P2PKH added a hash layer on top of P2PK. Instead of embedding the full public key in the locking script, P2PKH stores only a 20-byte RIPEMD-160 hash of the public key:

// P2PK locking script (35 bytes with compressed key)
<pubkey> OP_CHECKSIG

// P2PKH locking script (25 bytes)
OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG

The P2PKH locking script is smaller (25 bytes vs. 35 or 67 bytes for P2PK), but the P2PKH unlocking script is larger because the spender must provide both the signature and the full public key. The net result is that P2PKH transactions are slightly larger overall, but the locking script savings matter because outputs remain in the UTXO set until spent, consuming memory on every full node.

Why P2PK Fell Out of Use

Three factors drove Bitcoin away from P2PK and toward hashed output types:

1. No address format: P2PK has no human-readable address. Users had to share raw public keys (66 or 130 hex characters), which are impractical to copy, QR-encode, or verify visually. P2PKH introduced Base58Check addresses starting with "1", which are shorter and include a checksum to catch typos.
2. Larger UTXO footprint: P2PK locking scripts with uncompressed public keys are 67 bytes, nearly three times the size of a 25-byte P2PKH locking script. Since every unspent output must be stored in memory by full nodes, smaller scripts reduce the resource cost of running the network.
3. Quantum vulnerability: P2PK exposes the elliptic curve public key from the moment coins are received. A sufficiently powerful quantum computer running Shor's algorithm could derive the private key from the exposed public key. Hashed outputs like P2PKH only reveal the public key when the coins are spent, giving an attacker a much smaller time window.

For a deeper look at how Bitcoin address formats evolved from P2PK to modern Taproot outputs, see the research article on Bitcoin address types from P2PKH to Taproot.

Use Cases

Early Coinbase Transactions

The original Bitcoin software used P2PK for all coinbase transactions (the special transaction that pays the block reward to the miner). Because mining software generated coins without a recipient providing an address, it simply used the miner's own public key directly in a P2PK output. Some older mining software continued this pattern well after P2PKH became standard.

Satoshi-Era Peer-to-Peer Transfers

Before Bitcoin had a user-friendly address system, early adopters sent coins directly to each other's public keys using the original Bitcoin client's "pay to IP address" feature. This feature created P2PK outputs and was removed from later versions of Bitcoin Core due to security concerns.

Taproot's Spiritual Successor

Interestingly, P2TR (Taproot) brings back the concept of paying directly to a key rather than a hash. In its key-path spend, a Taproot output locks to a tweaked public key and is spent with a single Schnorr signature: structurally similar to P2PK but with critical upgrades including key tweaking for script commitments and batch verification.

Risks and Considerations

Quantum Computing Threat

P2PK outputs are the most quantum-vulnerable Bitcoin outputs. Because the public key sits permanently on the blockchain, an attacker with a cryptographically relevant quantum computer could work through exposed P2PK keys at their leisure. Research from 2026 estimates that approximately 1.7 million BTC remain in legacy P2PK outputs, representing a significant portion of the roughly 6.9 million BTC with exposed public keys across all output types.

Proposals like BIP-360 aim to introduce post-quantum cryptographic spending paths for Bitcoin, but migrating coins locked in P2PK outputs requires the original private key holder to move them voluntarily: nobody else can do it. Satoshi's estimated 1 million BTC in P2PK outputs would remain vulnerable unless moved.

No Address Checksum

Without an address format, there is no checksum to catch errors when specifying a P2PK recipient. A single incorrect character in a raw public key would lock coins to an invalid key, making them permanently unspendable. Modern address encodings like Base58Check and Bech32 include checksums specifically to prevent this kind of loss.

UTXO Set Bloat

Unspent P2PK outputs with uncompressed 65-byte public keys consume more memory in the UTXO set than any modern output type. Because these outputs date from Bitcoin's earliest blocks and many will never be spent (lost keys, Satoshi's coins), they represent a permanent overhead cost for every full node on the network.

P2PK in the Modern Bitcoin Stack

While P2PK is no longer used for new transactions, understanding it is essential for anyone working with Bitcoin's scripting system. It represents the simplest possible spending condition and serves as the conceptual foundation for every script type that followed. Modern layer-2 solutions like Spark build on the full evolution of Bitcoin's script system, leveraging Taproot outputs that circle back to P2PK's key-based simplicity while adding the security and flexibility that P2PK lacked.

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.