Glossary

Public Key

A point on the secp256k1 elliptic curve derived from a private key, used to verify signatures and generate Bitcoin addresses.

Key Takeaways

  • A public key is a point on the secp256k1 elliptic curve, derived from a private key through one-way scalar multiplication that cannot be reversed with classical computers.
  • Public keys come in three formats: uncompressed (65 bytes), compressed (33 bytes), and x-only (32 bytes for Taproot). Bitcoin addresses are derived by hashing the public key, hiding it until the owner spends funds.
  • Quantum computers running Shor's algorithm could theoretically reverse the derivation: address hashing adds a protective layer, but spending reveals the key and removes that shield.

What Is a Public Key?

A public key in Bitcoin is a coordinate pair (x, y) on the secp256k1 elliptic curve. It serves as the cryptographic identity tied to a wallet: anyone can use it to verify that a digital signature was created by the corresponding private key holder, without ever learning the private key itself.

Every Bitcoin transaction that moves funds requires a valid signature checked against a public key. When you send bitcoin, your wallet signs the transaction with your private key, and the network verifies that signature using your public key. This asymmetric relationship is the foundation of self-custody: whoever controls the private key controls the funds, and the public key proves it.

Bitcoin addresses are not public keys themselves. They are hashes or encodings of public keys, which adds a layer of indirection that improves both privacy and security. The public key is only revealed on-chain when the owner spends from that address.

How It Works

The public key is derived from the private key using elliptic curve scalar multiplication on the secp256k1 curve (defined by y² = x³ + 7 over a large prime field). The formula is:

Public Key = private_key × G

Where:
  private_key = a random 256-bit integer (32 bytes)
  G           = the generator point (a fixed point on secp256k1)
  ×           = elliptic curve scalar multiplication (repeated point addition)

The result is a new point on the curve with an x-coordinate and a y-coordinate, each 32 bytes long. This multiplication is a one-way trapdoor function: computing the public key from the private key takes microseconds, but reversing it (the elliptic curve discrete logarithm problem) is computationally infeasible for classical computers.

Compressed vs. Uncompressed Formats

Because the secp256k1 curve equation is deterministic, knowing the x-coordinate plus one bit of information about y is enough to reconstruct the full point. This gives rise to three encoding formats:

FormatSizePrefixContent
Uncompressed65 bytes0x04prefix + 32-byte x + 32-byte y
Compressed33 bytes0x02 or 0x03prefix + 32-byte x (02 = even y, 03 = odd y)
X-only (Taproot)32 bytesNone32-byte x (even y assumed per BIP-340)

Early Bitcoin (pre-2012) used uncompressed keys by default. Modern wallets use compressed keys for P2WPKH addresses and x-only keys for P2TR (Taproot) addresses. Compressed and uncompressed encodings of the same private key produce different addresses because the hash input differs.

From Public Key to Address

Bitcoin addresses hide the public key behind a hash. For legacy P2PKH addresses (starting with "1"), the derivation works as follows:

  1. Take the compressed public key (33 bytes)
  2. Apply SHA-256, producing 32 bytes
  3. Apply RIPEMD-160 to the SHA-256 result, producing 20 bytes (this combined operation is called HASH160)
  4. Prepend a version byte and append a checksum
  5. Encode the result with Base58Check
HASH160 = RIPEMD-160(SHA-256(public_key))

Example:
  Public key: 02e3af28965693b9ce1228f9d468149b831d6a0540b25e8a9900f71372c11fb277
  HASH160:    1e51fcdc14be9a148bb0aaec9197eb47c83776fb
  Address:    13gJBHMxcMZuTGBAKxn1DFqJpLMjNTpvMk

For SegWit P2WPKH addresses (starting with "bc1q"), the same 20-byte HASH160 is encoded with Bech32 instead of Base58Check. For Taproot P2TR addresses (starting with "bc1p"), the 32-byte x-only public key is used directly (no hashing) and encoded with Bech32m. For a comprehensive comparison of all address types, see the Bitcoin address types guide.

Signature Verification

The primary purpose of a public key is to verify that a transaction was authorized by the private key holder. Bitcoin uses two signature algorithms on the secp256k1 curve:

AlgorithmSignature SizeKey SizeUsed In
ECDSA70-72 bytes (DER-encoded)33 bytes (compressed)P2PKH, P2WPKH
Schnorr (BIP-340)64 bytes (fixed)32 bytes (x-only)P2TR (Taproot)

When a node processes a transaction, the OP_CHECKSIG opcode pops the public key and signature from the stack, hashes the transaction data according to the SIGHASH flag, and verifies the signature against that hash. If verification succeeds, the spend is authorized. Schnorr signatures also enable linear key aggregation, allowing multiple signers to produce a single compact signature: this is the basis for protocols like MuSig2 and FROST threshold signatures.

When Public Keys Are Revealed

A critical property of Bitcoin's address design: public keys are hidden until the owner spends. This has direct security implications.

Address TypeKey in Output?Revealed at Spend?Where?
P2PK (legacy, 2009-era)Yes, in scriptPubKeyAlready exposedscriptPubKey
P2PKH (starts with "1")No, only HASH160YesscriptSig
P2WPKH (starts with "bc1q")No, only HASH160YesWitness data
P2TR (starts with "bc1p")X-only key in outputAlready encodedWitness program

Once you spend from a P2PKH or P2WPKH address, the public key is permanently recorded on the blockchain. Any remaining balance at that address, or future payments sent to it, loses the hash-based protection. This is a key reason why address reuse is discouraged.

Why It Matters

Public keys are the cryptographic anchor of Bitcoin ownership. They enable trustless verification: anyone can confirm a transaction is valid without needing to trust the sender, a bank, or any intermediary. This property makes self-custodial wallets possible and underpins the entire Bitcoin security model.

For developers building wallet infrastructure, understanding public key derivation is essential. Modern HD wallets use BIP-32 extended keys to derive entire trees of public keys from a single seed phrase, following standardized derivation paths like BIP-84 (for P2WPKH) or BIP-86 (for P2TR). Layer 2 protocols like Spark extend this model by using public keys within off-chain transaction signing, enabling instant transfers while preserving the same cryptographic guarantees.

Use Cases

  • Transaction authorization: every Bitcoin transaction requires a signature verified against the sender's public key via OP_CHECKSIG
  • Address generation: public keys are hashed to create P2PKH and P2WPKH addresses, or used directly in P2TR outputs
  • Multi-signature schemes: multisig wallets combine multiple public keys to require m-of-n signatures for spending, improving key management security
  • Threshold signatures: threshold signature protocols like FROST aggregate public keys so that t-of-n signers can produce a single valid signature indistinguishable from a single-key spend
  • Identity verification: public keys serve as pseudonymous identities on the network, enabling proof of ownership for messages and transactions without revealing personal information

Risks and Considerations

Quantum Computing Threat

The most significant long-term risk to public key cryptography is quantum computing. Shor's algorithm running on a sufficiently powerful quantum computer could solve the elliptic curve discrete logarithm problem, deriving a private key from its public key. As of 2026, no quantum computer is large enough to threaten secp256k1, but the Bitcoin community is actively preparing.

Hash-based addresses (P2PKH, P2WPKH) provide a buffer: because the public key is hidden behind SHA-256 and RIPEMD-160, a quantum attacker cannot target unspent outputs where the key has never been revealed. However, the moment a transaction is broadcast and the public key enters the mempool, there is a window of exposure before the transaction confirms. Approximately 6.5 million BTC currently sit in addresses with exposed public keys (P2PK outputs and reused addresses). For a deeper analysis, see the post-quantum cryptography threat assessment.

Address Reuse Degrades Protection

Spending from an address reveals the public key on-chain permanently. If you receive additional funds to that same address, those funds lose the hash-based quantum protection. Using a fresh address for every transaction (standard practice in HD wallets) ensures your public keys remain hidden until the moment of spending.

Key Exposure in Transit

When a transaction is broadcast but not yet confirmed, the public key is visible in the mempool. In a post-quantum scenario, an attacker could theoretically observe the public key, derive the private key, and broadcast a competing transaction before the original confirms. Proposals like BIP-360 (Pay-to-Quantum-Resistant-Hash) aim to introduce new address types that resist this attack vector.

Backup and Recovery

Public keys themselves do not need to be backed up independently: they can always be regenerated from the private key or seed phrase. However, losing the private key means permanent loss of access. Hardware signing devices and cold storage protect private keys from exposure while still allowing public key derivation for address generation and balance monitoring.

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.