Public-Key Cryptography & secp256k1

Hash functions gave us a one-way fingerprint. Public-key crypto gives us a one-way identity: a pair of numbers where you can hand one to the whole world and keep the other secret forever, and no amount of staring at the public one reveals the secret. That asymmetry is what lets a stranger verify you authorized a spend without you ever showing them your key. This page is about where that asymmetry comes from — and the specific curve, secp256k1, that Bitcoin bets everything on.

The whole idea in one sentence

A private key is a secret number d. A public key is a point Q = d · G on an elliptic curve. Computing Q from d is fast; recovering d from Q is — as far as anyone knows — computationally impossible.

That last clause is the entire foundation. It is not encryption (nothing is hidden and later recovered); it’s a trapdoor: easy one way, ruinously hard the other.

   private key  d  ──────  d · G  (fast: ~256 doublings) ─────►  public key  Q
        ▲                                                              │
        └────────  recover d from Q ?  (≈ 2¹²⁸ work — infeasible) ◄────┘

What an elliptic curve actually is here

secp256k1 is the set of points (x, y) satisfying a single short equation, taken over a giant prime field (arithmetic done mod p, so there are no decimals — just integers that wrap around):

   y² = x³ + 7   (mod p)

   p = 2²⁵⁶ − 2³² − 977
     = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F

You can “add” two points on the curve with a geometric rule (draw a line through them; it hits the curve at a third point; reflect it). Add a point to itself and you get point doubling. Do that over and over — G + G + … + G, d times — and you have scalar multiplication, written d · G. A clever trick called double-and-add computes d · G in about 256 steps even when d is a 256-bit number, which is why signing is fast.

The reverse — “I see Q and the public generator G; which d gives d·G = Q?” — is the Elliptic-Curve Discrete Logarithm Problem (ECDLP). There is no known shortcut; the best general attack (Pollard’s rho) needs about √n ≈ 2¹²⁸ operations. That’s the trapdoor.

By the numbers — the constants Bitcoin hard-codes

Every Bitcoin node ships these exact secp256k1 parameters, and consensus depends on all of them matching bit-for-bit:

Constant	Value	Role
p (field prime)	2²⁵⁶ − 2³² − 977	the modulus all coordinate math wraps around
a, b	0, 7	the curve is y² = x³ + 7
G (generator)	x = 79BE667E…16F81798	the fixed base point everyone multiplies
n (group order)	FFFFFFFF…D0364141 ≈ 1.158 × 10⁷⁷	how many distinct private keys exist
h (cofactor)	1	every curve point is usable — no small-subgroup traps

A private key is any integer in [1, n − 1]. So the key space is ~1.16 × 10⁷⁷ — close to 2²⁵⁶. For scale, there are roughly 10⁸⁰ atoms in the observable universe. Guessing a specific funded key is not “hard,” it is physically out of the question: you could brute-force a billion billion keys per second for the age of the universe and not make a dent.

Compressed vs uncompressed public keys

A public key is a point — two 256-bit coordinates, (x, y). But the curve equation means that for any valid x there are only two possible y values (one even, one odd), since y and −y are the two square roots. So you don’t need to store y at all — just x plus one bit saying which root:

   uncompressed :  04 ‖ x (32B) ‖ y (32B)            = 65 bytes
   compressed   :  02 or 03 ‖ x (32B)                = 33 bytes
                   └─ 02 = y is even, 03 = y is odd

Compressed keys (33 bytes) are the modern default — they shrink every transaction that reveals a public key. The receiver recomputes y from x using the curve equation. (This compressed/ uncompressed choice even changes the resulting address, because the address is a hash of these exact bytes — see Addresses & Encoding.)

From public key to address (why your address isn’t your key)

You rarely hand out a raw public key; you hand out a hash of it. The classic pipeline:

   pubkey ──SHA-256──► ──RIPEMD-160──►  20-byte "hash160"  ──+version, Base58Check──►  1... address

This is hashing (Part 1’s first primitive) reused for two jobs: it shortens the key to 20 bytes, and it adds a layer of protection — an attacker only sees the hash of your public key until you spend, buying a sliver of quantum-resistance margin. Ownership is proved later, at spend time, with a signature.

Under the hood — why “just try values” and “just solve it” both fail

Two instincts everyone has, and why each dies:

1. Brute force the key. Covered above — 2²⁵⁶ is a wall no hardware crosses.
2. Solve the discrete log algebraically. Over ordinary integers, d = log(Q)/log(G) would be easy. But this group is finite and cyclic — the points cycle through all n values with no order, no “bigger/smaller,” nothing for an algorithm to climb. The structure that makes scalar multiplication well-defined is exactly the structure that erases every gradient an attacker could follow. That is the deep reason the trapdoor holds.

It actually happened — “brain wallets” and the entropy trap

The math is bulletproof; human-chosen randomness is not. Around 2011–2015 people made “brain wallets” by setting their private key to SHA-256("a passphrase I'll remember"). The curve was never broken — but attackers precomputed the hashes of millions of common phrases, song lyrics, and Bible verses, then watched the chain. Funds sent to a brain-wallet address were swept within seconds. Researchers later catalogued thousands of drained brain wallets. The lesson is permanent: the security isn’t in the curve, it’s in the 256 bits of genuine entropy behind d. A key that a human could recall is a key a machine can guess. (This is exactly why wallets derive keys from BIP39 seed phrases with real entropy instead.)

The thread

How does this help untrusting strangers agree on one ledger? It lets the ledger name owners without a registry. There is no database mapping people to accounts that someone must maintain and be trusted to keep honest — an “account” is simply whoever can produce the private key behind a public point, and anyone can check that claim with arithmetic alone. Strangers don’t agree on who you are; they agree on math that only the key-holder can satisfy. Next we see how that satisfaction is demonstrated, in Digital Signatures (ECDSA & Schnorr).

The architect’s lens

• Why does it exist? To give the ledger a one-way identity: a secret d and a public point Q = d·G where computing Q is fast (256 double-and-add steps) but recovering d is the ECDLP (2¹²⁸ work) — so you can publish one key and keep the other forever.
• What problem does it solve? Ownership without a registry — an “account” is simply whoever can produce the key behind a public point, and any stranger checks that claim with arithmetic alone, no trusted database of who-owns-what.
• What are the trade-offs? Security rests entirely on the ECDLP holding and on d carrying genuine 256-bit entropy — the curve is bulletproof but human-chosen keys (brain wallets) get swept in seconds; and every node must hard-code the exact secp256k1 constants (p, G, n, cofactor 1) bit-for-bit, or consensus splits.
• When would you choose differently? secp256k1 was Satoshi’s bet for speed and being non-NIST-generated; other goals point elsewhere — Ed25519 for stronger nothing-up-my-sleeve guarantees, or a post-quantum scheme, since the ECDLP would fall to a large quantum computer (the hash160 address layer only buys a margin).
• What breaks if I remove it? There’s no way to name owners or authorize spends — signatures are built directly on Q = d·G, so without the trapdoor anyone could derive anyone’s secret and the whole authorization model collapses.

Check your understanding

1. State the trapdoor at the heart of public-key crypto in terms of d, G, and Q. Which direction is fast, and which is infeasible?
2. The curve is y² = x³ + 7 (mod p). Given only a valid x, how many y values are possible, and how does that fact let a public key compress from 65 bytes to 33?
3. Roughly how large is Bitcoin’s private-key space, and why does that make brute force pointless rather than merely “slow”?
4. Brain wallets used an unbroken curve yet still got drained. What was the actual weakness, and what does that tell you about where Bitcoin’s key security really lives?
5. Why do we hand out a hash of the public key (an address) instead of the public key itself?

Show answers

1. A private key d is a secret integer; the public key is the curve point Q = d · G. Computing Q from d is fast (~256 double-and-add steps); recovering d from Q is the ECDLP, needing about 2¹²⁸ operations — infeasible. Fast forward, impossible backward.
2. Exactly two y values (one even, one odd — the two square roots y and −y). So you store x plus a single prefix byte (02 even, 03 odd) and recompute y from the curve equation, shrinking 65 bytes to 33.
3. About 1.16 × 10⁷⁷ keys (the order n, close to 2²⁵⁶). That’s near the count of atoms in the observable universe — so guessing a specific funded key isn’t slow, it’s physically impossible within any timescale or energy budget.
4. The weakness was entropy: keys derived from memorable phrases have far fewer than 256 bits of real randomness, so attackers precomputed and swept them. Security lives in the genuine randomness behind d, not in the curve.
5. Hashing shortens the key to 20 bytes and adds protection — only the hash of your public key is public until you spend, so the raw key (and any future attack surface against it) stays hidden longer.