Overview — Cryptography & Addresses

The book’s throughline is one question: how do untrusting strangers agree on the state of a shared world computer — and what does it cost to run one? Before any of them can agree on the state, they need a way to say whose state it is. That is what this part builds. And the surprising answer, the one this whole part exists to earn, is that on Ethereum there is no whose — there is only who can sign.

If you have read the Bitcoin · First Principles cryptography part, you already own most of the machinery. Ethereum reuses the same elliptic curve, the same “a private key is a huge random number” idea, the same “a signature proves control without revealing the key.” What changes is the plumbing on top: a different hash function, a rawer address format, and a signature scheme that carries an extra byte so the signer’s address can be recovered from the signature itself. This overview draws the whole pipeline once, so every later page has a place to slot into.

An account is derived, not registered

Open a bank account and a registrar creates a row for you: a human institution decides you exist, and could decide you don’t. An Ethereum account has no registrar. It is derived, offline, from a single random secret — a number you can generate on an airplane with no network, and which nobody, anywhere, has to approve or even know about. The instant you pick that number, the account exists; the network finds out only the first time you use it.

That inverts the usual question. “Who are you?” — the thing an identity system normally answers — collapses into “who can produce a valid signature for this address?” There is no separate notion of identity to steal or forge. Control is identity. Lose the secret and you are, in the only sense the protocol understands, no longer that account. Copy the secret and the copier is now, equally and indistinguishably, that account.

   a bank account                     an Ethereum account
   ──────────────                     ────────────────────
   registrar creates a row            you pick a random 256-bit number
   identity is an external fact       identity = "can sign for this address"
   the bank can freeze / reverse      no one can freeze; a spend is final
   recovery = prove you're you        recovery = still holding the secret

Everything else in this part is the mechanical road from that one secret to a usable, hashable, signable account.

The spine: one secret to an address and back

Here is the entire pipeline on one page. Read it top to bottom once; each later page zooms into exactly one arrow.

   private key            256-bit random number  (the whole secret)
        │
        │  elliptic-curve multiplication on secp256k1  (one-way)
        ▼
   public key             a point (x, y) on the curve  — 64 bytes
        │
        │  Keccak-256 hash of those 64 bytes
        ▼
   32-byte digest
        │
        │  keep the LAST 20 bytes
        ▼
   address                0x + 20 bytes  (what you share, what state is keyed by)


   ...and to prove control of that address:

   message ──┐
             ├─► ECDSA sign with private key ─► signature (v, r, s)
   priv key ─┘
                                                     │
             address ◄── keep last 20 bytes of ◄── Keccak-256 ◄── recover public key from (v, r, s)

Two directions, and the asymmetry is the point. Going down — secret to address — is easy and one-way: multiply, hash, truncate. Going up — address back to the secret — is computationally impossible, which is exactly why publishing your address gives nothing away. The signature at the bottom is the clever closing move: given a message and a (v, r, s) signature, anyone can run the recovery step, land on a public key, hash it, and check whether the last 20 bytes match the address that is trying to spend. No lookup table, no registry — the address that authorized the transaction falls out of the signature.

Why each step is the step it is

256-bit random number. The secret must be drawn from a space so large that guessing is hopeless (2^256 is more numbers than there are atoms in the observable universe, give or take many orders of magnitude). Randomness quality is the whole ballgame here — a predictable secret is a stolen account, as the incidents later in this part show.
secp256k1 multiplication. Multiplying the curve’s fixed generator point by your secret yields a public point. The operation is trivial forwards and believed infeasible to invert (the elliptic-curve discrete-log problem). This is the trapdoor the whole scheme rests on.
Keccak-256. Ethereum runs the 64-byte public key through Keccak-256, a 256-bit hash. Hashing the key (rather than publishing it) shortens the address and adds a second wall: even a future break of the curve would still face the hash.
Last 20 bytes. The address is simply the low 20 bytes of that 32-byte digest. Twenty bytes (160 bits) is short enough to be human-shareable and long enough that collisions are infeasible.

What is the same as Bitcoin, and what is not

If Bitcoin’s cryptography part is fresh, anchor the new material against it. The curve is identical — both chains use secp256k1, so the “private key → public key” step is byte-for-byte the same idea. Everything downstream diverges.

Step	Bitcoin	Ethereum
Elliptic curve	secp256k1	secp256k1 (same)
Address hash	SHA-256 then RIPEMD-160	Keccak-256, once
Address length	20 bytes (HASH160)	20 bytes (last 20 of the digest)
Address encoding	Base58Check / Bech32 (with checksum)	raw hex `0x…`, optional EIP-55 mixed-case checksum
Signature	ECDSA `(r, s)`, pubkey supplied separately	ECDSA `(v, r, s)` — the `v` lets you recover the pubkey
”Who signed?“	verify against a supplied public key	recover the signer’s address from the signature

The single most Ethereum-specific idea in that table is the last row. Bitcoin hands you the public key and asks you to verify a signature against it. Ethereum bakes an extra recovery byte, v, into every signature so that the signer’s public key — and therefore address — can be reconstructed from the signature and the message alone. That is why an Ethereum transaction never carries a separate “from” field that you have to trust: the from is derived from the signature, so it cannot lie. The signatures page is where that trick pays off.

   secret keyspace              ≈ 2^256  ≈ 1.16 × 10^77 numbers
   observable-universe atoms    ≈ 10^80  (same ballpark, a few orders up)
   fastest guessing you can buy: pretend 10^18 guesses/sec (a wild over-estimate),
   across 10^10 machines, for 10^10 years (~ age of universe):
        10^18 × 10^10 × 10^10 × 3.15×10^7  ≈ 3 × 10^45 guesses
        fraction of keyspace covered       ≈ 3×10^45 / 1.16×10^77  ≈ 10^-32

You would search a vanishing sliver of the space — of order 10^-32 of it. This is why “just pick a random number” is a safe way to create an account — provided the randomness is real. The failures later in this part are always failures of that proviso, never of the arithmetic.

Roadmap for this part

Read these in order. Each page introduces one component of the pipeline above and forces one idea you cannot skip.

#	Page	Component it introduces	Idea it forces
2	secp256k1: Keys as Points on a Curve	private key → public key	A public key is a point; the map from secret to point is a one-way trapdoor.
3	Keccak-256: Ethereum’s Hash	the hash function	Why Ethereum uses Keccak-256 and how it differs from the later, standardized SHA-3.
4	From Public Key to a 20-Byte Address	public key → address	Truncation, the `0x` hex form, and the EIP-55 mixed-case checksum.
5	ECDSA Signatures and Recovery (v, r, s)	the signature	How `(v, r, s)` proves control and lets the signer’s address be recovered.
6	Keystores and Mnemonics	storing the secret	Where the secret actually lives: encrypted keystores and BIP-39 seed phrases.
900	Revision — Cryptography & Addresses	—	The whole pipeline recalled from memory.

The thread

Keep the book’s question in view: how do untrusting strangers agree on the state of a shared world computer? This part answers the sub-question hiding inside it — how does the world computer know a given change is authorized without trusting anyone? The answer is that authorization is not a permission someone grants; it is a mathematical fact anyone can check. A valid signature over a transaction, recovering to the address whose balance is being spent, is self-evidently authorized. No node has to trust that Alice sent it; every node can verify it independently and reach the same verdict. That is the atom of trustless agreement, and every later part — transactions, gas, the EVM, consensus — is built on top of it.

What this part deliberately leaves out

To keep the spotlight on keys, hashes, addresses, and signatures, several things are pushed to later parts on purpose:

What a transaction actually contains — the fields, nonce, RLP encoding, and the exact bytes that get hashed and signed. Signatures here sign an abstract “message”; the concrete transaction structure comes later.
Gas and fees — what it costs to have a signed transaction executed. This part only proves who is allowed to act, not what the action costs.
The EVM and smart contracts — contract accounts have addresses too, but they are derived differently (from the creator’s address and nonce, not from a keypair) and have no private key at all. That distinction belongs with the account model and the VM.

If you have worked through the companion ethmini crate, note one honest seam: to stay small, it does not model real signatures or Keccak — a transaction’s from field simply stands in for “the address a valid signature would have recovered to,” and it hashes with SHA-256. This part is where that stand-in gets unpacked into the real cryptography it abbreviates.

Check your understanding

Ethereum has no registrar for accounts. What single act brings an account into existence, and what does “who are you?” reduce to once it does?
Write out the four-step pipeline from a private key to an address, naming the operation at each arrow. Which step is one-way, and why does that matter for sharing your address?
Bitcoin and Ethereum share the same elliptic curve but differ almost everywhere downstream. Name two concrete differences in how each turns a public key into an address.
What extra information does an Ethereum signature carry that a bare Bitcoin (r, s) signature does not, and what does that extra information let any verifier do?
Restate, in one sentence, how this part answers the book’s throughline question about untrusting strangers agreeing on shared state.

Show answers

Picking a single random 256-bit secret brings the account into existence — offline, with no approval, the moment the number is chosen. “Who are you?” reduces to “who can produce a valid signature for this address?”: control is identity.
private key →(elliptic-curve multiplication on secp256k1)→ public key (a point) →(Keccak-256 hash)→ 32-byte digest →(keep the last 20 bytes)→ address. The multiplication (and the hash) are one-way: you cannot run them backwards to recover the secret from the address, which is exactly why publishing the address is safe.
Bitcoin hashes the public key with SHA-256 then RIPEMD-160 and encodes the result in Base58Check/Bech32 with a built-in checksum; Ethereum hashes once with Keccak-256, keeps the last 20 bytes, and presents it as raw 0x hex (with an optional EIP-55 mixed-case checksum). Either difference is a correct answer.
It carries a recovery byte v (making it (v, r, s) rather than (r, s)). That byte lets any verifier recover the signer’s public key — and therefore address — from the signature and message alone, so the transaction needs no separately-trusted “from” field.
Untrusting strangers agree on who is allowed to change the shared state because authorization is not a granted permission but a checkable mathematical fact — a signature recovering to the spending address — that every node verifies independently and agrees on.