Private Keys, Public Keys & Signatures

Everything a wallet does rests on one asymmetry: it is trivial to go from a private key to a public key, and astronomically hard to go back. From that single one-way street you get the entire idea of digital ownership — the ability to prove “this is mine” to strangers who don’t know you, don’t trust you, and never will. This page builds keys and signatures from the number up.

A private key is just a number

Strip away the mystique: a Bitcoin private key is a 256-bit integer — a number somewhere between 1 and roughly 2²⁵⁶. That’s it. No factory, no registrar, no central issuer. You “make” a key by generating 256 random bits with good entropy.

private key  =  a single random number, ~2^256 possibilities
             =  e.g. (EXAMPLE ONLY — never a real key)
                0x1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD

How big is 2²⁵⁶? About 10⁷⁷ — comparable to the number of atoms in the observable universe. This is why “just guess someone’s key” is not an attack: you could guess a billion keys a second for the age of the universe and never land on a used one. Security comes from the size of the haystack, not from anyone guarding it.

Randomness is the whole game

A key is only as secret as its randomness is unpredictable. Keys generated from weak entropy — a broken random number generator, a “brain wallet” made from a passphrase, dice rolled lazily — have been swept within seconds. The number must be drawn from the full space, uniformly. Bad entropy is the most common way self-made keys are lost.

The public key: one-way derivation on secp256k1

Bitcoin derives the public key by multiplying a fixed point on an elliptic curve by your private key. The curve is secp256k1, and it has a publicly known generator point G. Your public key is simply:

public key  =  private key × G        (elliptic-curve point multiplication)

This “multiplication” is not ordinary arithmetic — it’s repeated geometric point addition on the curve, done modulo a huge prime. The crucial property is that it is easy forward, infeasible backward:

• Given the private key k, computing K = k × G is fast.
• Given the public key K, recovering k requires solving the elliptic-curve discrete logarithm problem — for secp256k1, that is believed to be computationally impossible.

This is the same flavor of one-way trapdoor you met with hash functions: cheap in one direction, hopeless in the other. The public key can be shared with the whole world; the private key never leaves your control.

   PRIVATE KEY ──(× G on secp256k1, easy)──► PUBLIC KEY ──(hash)──► ADDRESS
        ▲                                                              │
        └──────── infeasible to reverse (discrete log) ───────────────┘

Each step throws away the ability to go back. That layering is exactly what lets you publish an address publicly while keeping spending power utterly private.

Signatures: proving ownership without revealing the key

Owning the key is useless unless you can prove it to skeptical strangers — and prove it without handing over the secret. That’s what a digital signature does.

A signature scheme has two operations:

sign(message, private key)        → signature
verify(message, signature, public key) → true / false

When you spend a coin, the “message” is (a hash of) the transaction itself. You sign it with the private key; anyone on the network can run verify using your public key. If it returns true, they know:

1. The signer held the private key matching that public key (authenticity), and
2. The exact transaction signed has not been altered by one bit (integrity) — change anything and the signature fails.

Crucially, verifying does not leak the private key. The signature is a fresh proof tied to this message; it can’t be peeled apart to recover the secret or replayed on a different transaction. This is the heart of trust-minimization: a miner in another country validates your spend with pure math, never needing to know who you are or to trust you.

Never reuse signature randomness

ECDSA signing requires a one-time random number, the nonce k. If the same nonce is ever reused for two different signatures, the private key can be algebraically recovered from the two signatures — this is exactly how several real wallets and even a game console were broken. Modern wallets use deterministic nonces (RFC 6979), deriving k from the key and message so it’s unique and reproducible without needing fresh randomness each time.

ECDSA vs Schnorr

Bitcoin originally used ECDSA (Elliptic Curve Digital Signature Algorithm). It works, but it’s quirky: signatures are a bit awkward to reason about, and they don’t combine cleanly.

The 2021 Taproot upgrade added Schnorr signatures on the very same secp256k1 curve. Schnorr is simpler, provably secure under cleaner assumptions, and has one superpower ECDSA lacks: signatures are linear, so multiple keys and signatures can be aggregated into one. Several signers can produce a single combined signature that looks identical to an ordinary single-key spend.

	ECDSA	Schnorr
Curve	secp256k1	secp256k1
Introduced	2009 (original)	2021 (Taproot)
Aggregation	no	yes (MuSig)
On-chain footprint	larger	smaller, uniform

That linearity is the foundation of MuSig key aggregation and a big privacy win — multisig spends become indistinguishable from single-sig ones. The full machinery lives in Taproot & Schnorr, and the privacy payoff in privacy & deanonymization.

Ownership = control of keys

There is no “account,” no name, no balance attached to you in Bitcoin. A coin is owned by whoever can produce a valid signature for the conditions locking it. Ownership is not a record in a database someone could edit — it is the ability to sign. Hold the key and you can move the coin; lose the key and the coin is unmovable; leak the key and someone else owns it. The wallet’s entire job is to guard that number.

It actually happened — when bad randomness leaked the keys (2010–2013)

The “never reuse a nonce” warning above has a body count. In December 2010, the group fail0verflow showed that Sony’s PlayStation 3 signed code with a constant ECDSA nonce — from two signatures the master signing key fell out by simple algebra. Then in August 2013, a flaw in Android’s SecureRandom caused several Bitcoin wallet apps to generate repeated signing nonces; attackers spotted the collisions on the public chain, recovered the private keys, and swept the affected coins. Same root cause both times: ECDSA’s security depends on a fresh, unpredictable nonce per signature, and a weak random source breaks it catastrophically. This is exactly why modern wallets switched to deterministic nonces (RFC 6979) — and why key security keeps returning to the theme that randomness is the whole game.

The architect’s lens

Step back from the curve arithmetic and ask the five questions that turn an implementer into an architect:

• Why does it exist? To make ownership a mathematical fact rather than a database entry: a 256-bit private key, a public key derived one-way via k × G on secp256k1, and a signature that proves control of the key without ever revealing it.
• What problem does it solve? Proving “this is mine” to strangers who’ll never trust you. The one-way derivation lets you publish the public key (and the address hashed from it) freely, while sign/verify gives every node authenticity and integrity — change one bit of the transaction and the signature fails.
• What are the trade-offs? Security rests entirely on hard assumptions and good randomness: the elliptic-curve discrete-log problem must stay infeasible, and ECDSA’s per-signature nonce must never repeat — reuse it across two signatures and the private key falls out by algebra (the PS3 and 2013 Android-SecureRandom breaks). RFC 6979 deterministic nonces patch the latter; quantum advances threaten the former.
• When is this the wrong design? ECDSA is the wrong choice when you want signature aggregation or cleaner proofs — that’s why Taproot added Schnorr on the same curve, enabling MuSig and multisig spends that look single-sig. For non-public, mutually-trusting parties a shared secret/MAC is simpler than asymmetric signatures.
• What breaks if I remove it? Everything — there are no accounts or names in Bitcoin, only “whoever can produce a valid signature.” Without keys and signatures there’s no way to assert ownership or authorize a spend, and the ledger has nothing to verify.

The thread

How does this help untrusting strangers agree on one ledger? Because ownership becomes a mathematical fact anyone can check. No registrar declares “this is Alice’s”; Alice simply produces a signature only her key could make, and every node on earth verifies it independently with the same arithmetic. Strangers don’t have to trust Alice — or each other — they only have to trust that the discrete-log problem is hard. That replaces human authority with verifiable math, which is the whole point.

Check your understanding

1. In what sense is a private key “just a number,” and why doesn’t its public nature make guessing it feasible?
2. Why can the public key be shared freely while the private key stays secret — what makes the derivation one-way?
3. What two things does verifying a signature prove, and why does verification not reveal the private key?
4. What is the nonce in ECDSA, and what happens if it is reused across two signatures?
5. Name two concrete advantages Schnorr has over ECDSA on the same curve.

Show answers

1. A private key is literally a 256-bit integer (between 1 and ~2²⁵⁶) generated from random entropy — no issuer or registrar. Guessing it is infeasible because the space is ~10⁷⁷ possibilities (about the atoms in the observable universe): security comes from the size of the haystack, not from anyone guarding it.
2. The public key is private key × G — elliptic-curve point multiplication on secp256k1, which is easy forward but infeasible backward (recovering the key requires solving the elliptic-curve discrete-log problem). So you can publish the public key (and the address hashed from it) to the world while the private key never leaves your control.
3. Verifying proves authenticity (the signer held the private key matching that public key) and integrity (the exact transaction signed wasn’t altered by one bit — change anything and the signature fails). Verification doesn’t leak the private key because the signature is a fresh proof tied to this message; it can’t be peeled apart to recover the secret or replayed elsewhere.
4. The nonce k is a one-time random number ECDSA signing requires. If the same nonce is reused across two different signatures, the private key can be algebraically recovered from the two signatures — a real-world break (wallets, a game console). Modern wallets use deterministic nonces (RFC 6979), deriving k from the key and message.
5. Any two of: Schnorr is simpler and provably secure under cleaner assumptions; its signatures are linear, so multiple keys/signatures can be aggregated into one (MuSig), making multisig spends indistinguishable from single-sig; and it has a smaller, more uniform on-chain footprint.