Timechain Wiki

Public key cryptography

12 min read

Public key cryptography is the foundational primitive Bitcoin uses to assign ownership of funds and to authorize their movement. Where symmetric cryptography uses one shared secret for both encryption and decryption, asymmetric cryptography uses a pair of mathematically linked keys: a private key (kept secret) and a public key (shared freely). The mathematical link runs in only one direction — the public key is derivable from the private key, but not the reverse. This one-way property lets the public key act as an identifier (or, after hashing, an address) while the private key acts as the spending authority. Bitcoin specifically uses the secp256k1 elliptic curve, a 256-bit curve Satoshi chose in 2008 over the NIST alternatives; its group structure, discrete-logarithm hardness, and key sizes are what every subsequent layer of Bitcoin's cryptography ultimately rests on. Deeper treatment of signing and verification lives in Signature schemes in Bitcoin; address derivation lives in Bitcoin addresses.

Why this note matters

Every other layer of Bitcoin’s cryptographic stack depends on public key cryptography functioning as advertised. Signatures (which prove authorization to spend) are constructed using private keys and verified using public keys. Addresses (which identify where funds can be sent) are derived from public keys. The integrity of self-custody — that holding the private key is sufficient to control funds, and that holding only the public key reveals only the ability to receive — collapses if the underlying primitive collapses.

The note is also the foundational reference point for the quantum-threat discussion: the practical risk Bitcoin’s cryptography faces from quantum computing is specifically that quantum algorithms can solve the discrete-logarithm problem that secp256k1’s security rests on. The post-quantum migration discussion lives in The post-quantum migration debate and the analytical engagement in Quantum computing threat to Bitcoin; both refer back to this note for the underlying mechanism.

Asymmetric versus symmetric cryptography

In symmetric cryptography, the same key encrypts and decrypts. Two parties who want to communicate privately must share the secret key, and that key must reach both parties through some out-of-band channel — itself a problem.

In asymmetric (public key) cryptography, each party has a pair of keys: a private key they never share, and a public key they distribute freely. The two are mathematically linked so that operations performed with one can be verified or reversed using the other. Critically, possession of the public key does not allow recovery of the private key.

This asymmetric property enables three operations Bitcoin uses:

  1. Identification. A public key (or a hash of it) identifies an owner without revealing how to spend.
  2. Authorization. A signature produced with a private key proves authorization to spend, verifiable by anyone with the public key.
  3. Verifiability without trust. A node validating a transaction needs only the public key (visible on the chain) to confirm a signature — no shared secret, no trusted third party.

Bitcoin uses public key cryptography for identification and authorization. It does not use it for encryption (transactions are public and unencrypted on the chain); the asymmetric primitive is purely for ownership and signing.

The mathematical setup

Bitcoin uses elliptic curve cryptography (ECC), a specific class of public key cryptography built around the algebraic structure of elliptic curves over finite fields. ECC provides equivalent security to older systems (RSA, DSA) at substantially smaller key sizes — a 256-bit ECC key is comparable in security to a 3072-bit RSA key.

At the conceptual level:

  • A curve is defined over a finite field (in Bitcoin’s case, a 256-bit prime field)
  • The points on the curve, together with a defined “addition” operation, form a mathematical group
  • A specific point on the curve, called the generator (G), is chosen as a starting reference
  • Multiplying G by an integer n produces another point on the curve, written as n·G
  • Given G and n, computing n·G is fast (it’s roughly O(log n) operations)
  • Given G and n·G, recovering n is hard — believed to require roughly 2^128 operations for a 256-bit curve

That asymmetry — easy in one direction, hard in the reverse — is the discrete logarithm problem on elliptic curves (ECDLP), and it is the cryptographic hardness assumption underlying every Bitcoin public key.

For the purposes of this note, the deeper mathematics is treated as a black box. What matters is:

  • A private key is a number (n)
  • A public key is a point (n·G)
  • Computing n·G from n is fast; recovering n from n·G is computationally infeasible

The secp256k1 curve

Bitcoin uses a specific elliptic curve called secp256k1, defined in the SEC (Standards for Efficient Cryptography) specification. The curve equation is y² = x³ + 7 over a 256-bit prime field; the specific prime, the specific generator point, and the specific group order are all fixed parameters of the standard.

Practical key sizes:

  • Private key: 256 bits (32 bytes). Any 256-bit integer between 1 and the curve’s group order is a valid private key; in practice the order is slightly less than 2^256, so essentially any 32-byte random value is valid.
  • Public key (uncompressed): 520 bits (65 bytes) — a 1-byte prefix (0x04) plus the x-coordinate (32 bytes) plus the y-coordinate (32 bytes). Rarely used in modern Bitcoin.
  • Public key (compressed): 264 bits (33 bytes) — a 1-byte prefix (0x02 or 0x03, encoding the parity of y) plus the x-coordinate (32 bytes). The standard form since BIP-66 era.
  • x-only public key: 256 bits (32 bytes) — just the x-coordinate, used in Taproot (BIP-340). Even more compact.

The compressed form is the dominant on-chain representation pre-Taproot; Taproot uses x-only public keys for additional compactness and for specific protocol properties around key aggregation.

Where Bitcoin uses public key cryptography

The primitive shows up at five distinct layers:

  • Identification. A public key (or a hash of it) identifies the owner of a UTXO. See Bitcoin addresses.
  • Signatures. Spending a UTXO requires producing a signature with the corresponding private key. See Signature schemes in Bitcoin.
  • Hierarchical deterministic (HD) wallets. BIP-32 derives a tree of child keys from a single master seed using the algebraic structure of secp256k1. See operational treatment in Seed phrases and BIP-39.
  • Schnorr key aggregation. In Taproot, multiple public keys can be added on the curve to produce a single aggregated key, enabling multisig that looks like single-sig on-chain. See Signature schemes in Bitcoin.
  • Multi-party signing protocols. Threshold signatures, FROST, MuSig2 — these all build on the algebraic structure of secp256k1 to compose signing operations across parties.

In short: every per-UTXO ownership and authorization mechanic in Bitcoin runs on public key cryptography.

Key generation

A Bitcoin private key is, mechanically, a random 32-byte number. The entire generation procedure is:

  1. Generate 32 bytes of cryptographically secure randomness
  2. Interpret as an integer
  3. Confirm it’s in the valid range (1 ≤ key < group order)
  4. Done — that’s the private key

The public key is then computed as private_key · G, where G is the secp256k1 generator. This computation is deterministic — the same private key always produces the same public key.

The security of the entire system hinges on the quality of the randomness in step 1. Poor randomness (predictable, biased, or accidentally reused) collapses the security. The historic 2013 Android wallet vulnerability — where a flaw in Java’s SecureRandom produced predictable keys — drained funds from affected wallets within hours. Hardware wallets exist in part to push key generation into a dedicated environment where randomness can be trusted.

In practice, Bitcoin wallets rarely generate a single key directly. Instead they generate a single random seed (typically 128 or 256 bits of entropy, encoded as a Seed phrases and BIP-39 mnemonic), and derive trees of keys from it using BIP-32 / BIP-39 / BIP-44 hierarchical derivation. The randomness still has to be high quality, but only one act of randomness has to be trustworthy; everything else is deterministic.

Properties the primitive provides (and doesn’t)

Properties provided:

  • One-way derivation. Public key derivable from private; reverse is computationally infeasible (under current cryptographic assumptions).
  • Determinism. A given private key always produces the same public key; signing is deterministic when using RFC 6979 (Bitcoin’s convention) or when using BIP-340 Schnorr.
  • Unforgeability. Producing a valid signature for a given public key without the private key is computationally infeasible.
  • Verifiability. Anyone with the public key can verify a signature.

Properties NOT provided:

  • Identity binding. A public key is just a number. It does not bind to a person, legal entity, or jurisdiction. Bitcoin addresses are pseudonymous; identity comes from external context (KYC at exchanges, chain-analysis heuristics, behavioral patterns) — not from the cryptography itself.
  • Privacy. Transactions are public on the chain. The cryptography proves authorization to spend; it does not hide what was spent, how much, or to whom. Privacy in Bitcoin comes from other mechanisms (CoinJoin, PayJoin, Stealth addresses and Silent Payments) layered on top.
  • Quantum resistance. secp256k1’s hardness assumption (the elliptic-curve discrete logarithm) is broken by Shor’s algorithm on a sufficiently capable quantum computer. The threat is engaged substantively in Quantum computing threat to Bitcoin.
  • Encryption. Bitcoin does not encrypt transaction data. The primitive is used for identification and signing only.

Tradeoffs and design choices

Why secp256k1 specifically? Satoshi chose secp256k1 in 2008 over the more widely used NIST P-256 curve. The cited reasons (and the post-hoc consensus interpretation) include:

  • Endomorphism. secp256k1 admits an efficient endomorphism (the GLV decomposition) that speeds up signature verification by roughly 25%. Validation efficiency matters for nodes, especially light-resource ones.
  • No NIST involvement. P-256’s parameters were chosen by NIST with some opaque steps that the cryptographic community has been historically suspicious of (the Dual_EC_DRBG backdoor incident in 2013 reinforced this concern). secp256k1’s parameters are simpler and more transparent — there’s no unexplained constant — though absolute trust in any specific curve is impossible without proving its absence of structure.
  • Adequate security. 256-bit elliptic curves provide roughly 128 bits of security against the best known attacks, which is considered well-sufficient for the foreseeable classical-computing era.

The choice was prescient. As of 2026, secp256k1 has held up cryptographically since 2009 across intense use spanning trillions of dollars in monetary value.

Key-size tradeoff. ECC’s 256-bit key size is dramatically smaller than RSA’s equivalent (~3072 bits), which matters for on-chain storage costs. A 33-byte compressed public key fits comfortably in a transaction output; a 384-byte RSA public key would not.

Compressed versus uncompressed public keys. Pre-2012, uncompressed public keys (65 bytes) were the default. Compressed keys (33 bytes) became standard, reducing transaction size by ~32 bytes per spend. Taproot’s x-only keys (32 bytes) shave another byte.

Why elliptic curves over RSA? RSA was the standard public-key cryptosystem in the pre-Bitcoin era, but its key sizes are larger, signing is slower, and verification is dominated by the costly modular-exponentiation operation. ECC was faster and more compact across every dimension that matters for Bitcoin.

Quantum threat as the structural limit. secp256k1 is not quantum-resistant. A cryptographically relevant quantum computer running Shor’s algorithm could recover private keys from public keys in polynomial time. For substantive engagement with this concern, see Quantum computing threat to Bitcoin (Criticisms section, analytical engagement) and The post-quantum migration debate (Controversies section, on which scheme Bitcoin should migrate to and when).

Open questions for further development

  • Will Bitcoin’s eventual post-quantum migration require changes to the underlying public-key primitive, or only to the signature scheme layered on top? Some candidate post-quantum signature schemes (FALCON, SPHINCS+) abandon ECC entirely; others (lattice-based schemes) replace just the hardness assumption.
  • How long does the gap remain between cryptographically relevant quantum computing capability and the deployment of post-quantum signature schemes in the Bitcoin protocol? This is the operational question that drives the migration debate.
  • What is the right policy for old, exposed public keys (UTXOs whose public key has been revealed via prior spends)? These are at higher quantum risk than P2PKH/P2WPKH UTXOs that have never been spent.
  • Does any future change to the curve (e.g., a hypothetical migration from secp256k1 to a different curve for non-quantum reasons) interact with the BIP-32 derivation tree in ways that would require wallet reorganization?

Canonical sources for this note

Reference texts

  • Mastering Bitcoin, Andreas Antonopoulos (chapter 4: “Keys, Addresses”) — the canonical engineering treatment of Bitcoin’s use of public key cryptography. See Mastering Bitcoin - Andreas Antonopoulos.
  • Programming Bitcoin, Jimmy Song (chapters 1-3) — working-programmer pedagogical treatment of secp256k1, finite-field arithmetic, and elliptic-curve operations.
  • Grokking Bitcoin, Kalle Rosenbaum — accessible treatment for the technically-curious-but-not-developer reader.

Cryptographic foundations (for the textbook level this note defers)

  • Handbook of Applied Cryptography, Menezes, van Oorschot, and Vanstone — the standard reference for the cryptographic primitives this note treats as black boxes.
  • Cryptography Engineering, Ferguson, Schneier, and Kohno — the engineering perspective on building systems with cryptographic primitives.

Bitcoin-specific specifications

  • SEC 2 — the specification document defining secp256k1. Free at sec.org.
  • BIP-32 — hierarchical deterministic wallets; defines how a single master key derives a tree of child keys using secp256k1 arithmetic.
  • BIP-340 — Schnorr signatures over secp256k1; defines x-only public keys.

Quantum threat research

  • Bitcoin & Quantum Computing, NVK (Rodolfo Novak) research series at bitcoinquantum.space — load-bearing for the post-quantum considerations. See Rodolfo Novak.
  • SHA-256 — The other foundational primitive; public-key operations frequently feed into SHA-256 hashing for address derivation.
  • Merkle trees — Uses SHA-256 over public-key-derived data; the structural composition of the cryptographic layer.
  • Signature schemes in Bitcoin — How public keys actually get used to sign transactions: ECDSA (the original) and Schnorr (Taproot, 2021).
  • Bitcoin addresses — How public keys are derived into the human-shareable address formats.
  • UTXO model and Bitcoin transactions — Where public keys live on the chain (in output script templates) and where signatures live (in input witness data).
  • Seed phrases and BIP-39 — The operational entry point: holders manage seed phrases, not raw keys. Self-custody section.
  • Quantum computing threat to Bitcoin — Substantive engagement on the quantum threat to public-key cryptography. Criticisms section.
  • The post-quantum migration debate — Event-level engagement on which post-quantum scheme Bitcoin should adopt and when. Controversies section.
  • Pieter Wuille — Long-time contributor to Bitcoin’s cryptographic refinements; co-author of BIP-340 Schnorr and BIP-341 Taproot.
  • Greg Maxwell — Adjacent cryptographic-protocol work including Confidential Transactions and many of the signing-protocol refinements over the years.

Graph View

Backlinks