Revision — Cryptography & Addresses

This part answered one narrow but foundational sub-question hiding inside the book’s throughline — how do untrusting strangers agree on the state of a shared world computer? Before anyone can agree on a change to that state, the network has to know the change is authorized. This part showed that authorization on Ethereum is not a permission some registrar grants; it is a mathematical fact anyone can check. An account is not a row someone creates for you — it is derived, offline, from a single random secret, and control of that secret is identity.

The overview drew the whole pipeline on one page. The five pages that followed each zoomed into exactly one arrow of it. This revision walks the spine one more time, in prose and from memory, so you can reconstruct it without the diagrams — and then hands the keys and addresses forward to the parts that will act on them.

The spine, from memory

Everything in this part is the mechanical road from one secret to a usable, hashable, signable account, and one closing trick that lets that account prove control. Recited as a chain:

random 256-bit secret
      │  elliptic-curve multiply on secp256k1   (one-way)
      ▼
public key = a point (x, y)      — 64 bytes
      │  Keccak-256 hash of those 64 bytes
      ▼
32-byte digest
      │  keep the LAST 20 bytes
      ▼
address = 0x + 20 bytes

  ...and to prove control:
  message + secret ─► ECDSA sign ─► (v, r, s)
  (v, r, s) + message ─► recover public key ─► Keccak-256 ─► last 20 bytes ─► address

The asymmetry is the entire point. Going down the chain — secret to address — is cheap and one-way: multiply, hash, truncate. Going up — address back to the secret — is believed computationally impossible, which is precisely why publishing your address gives nothing away. The signature at the bottom closes the loop: given a message and a (v, r, s), anyone can recover a public key, hash it, truncate it, and check whether the resulting address matches the one trying to spend. The from of a transaction is never asserted; it falls out of the signature.

One secret, one point on a curve

The secp256k1 page established the trapdoor the whole scheme rests on. A private key is nothing more than a huge random number — a 256-bit integer drawn from a space of roughly 2^256 values, so vast that guessing is hopeless provided the randomness is real. Multiply the curve’s fixed generator point G by that secret, and you land on another point on the curve: your public key. That multiplication is trivial forwards and believed infeasible to invert — the elliptic-curve discrete-log problem. You can hand out the point freely; nobody can walk it back to the scalar that produced it.

Ethereum and Bitcoin share this curve byte for byte. If you carried the intuition over from the Bitcoin · First Principles cryptography part, the “private key → public key” step needed no relearning. Everything downstream is where the two chains diverge.

Keccak-256, not SHA-3

The Keccak-256 page covered the first Ethereum-specific choice, and it is a subtle one worth stating precisely. Ethereum hashes the 64-byte public key with Keccak-256 — the original Keccak submission, standardized in the padding-and-parameters form that predates the final NIST standard. When NIST finalized SHA-3 in 2015 (FIPS 202), it changed the padding rule. Ethereum had already shipped with the original Keccak, so Ethereum’s keccak256 is not the same function as SHA3-256: feed the same input to both and you get different digests. This is a genuine, permanent gotcha — libraries expose keccak256 and sha3_256 as distinct functions, and using the wrong one produces valid-looking but wrong hashes and, therefore, wrong addresses.

Hashing the key rather than publishing it directly buys two things: a shorter address, and a second wall — even a future break of the curve would still leave an attacker facing the hash.

Public key to a 20-byte address

The address page took the 32-byte Keccak digest and threw most of it away: the address is simply its last 20 bytes, presented as 0x followed by 40 hex characters. Twenty bytes — 160 bits — is short enough to be human-shareable and long enough that finding a collision is infeasible.

Two small details on that page carry outsized weight because they touch consensus and safety, not just ergonomics:

• EIP-55 checksumming. Raw hex has no error detection — mistype one character and you have a different, probably-nonexistent address, and any funds sent there are gone with no reversal. EIP-55 mixes the case of the hex letters (a–f) according to a Keccak hash of the lowercase address. A conforming wallet re-derives that casing and rejects an address whose capitalization does not match. Crucially this needs no change to the protocol or the address format — a checksummed address is still the same 20 bytes; the case is a free error-detecting layer that older tools simply ignore.
• Contract addresses have no keypair. A contract’s address is derived from its creator’s address and nonce (or, for CREATE2, from a salt and the init code), not from a private key. A contract is an account with code and storage but no secret — it cannot sign; it can only be called. That distinction belongs with the account model and the EVM, but it is why “every address is a hashed public key” is almost true and worth qualifying.

ECDSA signatures and recovery — the closing trick

The signatures page delivered the single most Ethereum-specific idea in the whole part, and the second choice-versus-Bitcoin. Bitcoin hands you a public key and asks you to verify an (r, s) signature against it. Ethereum bakes an extra recovery byte v into every signature, making it (v, r, s). That byte pins down which of the candidate public keys the signature mathematically implies is the real signer. So from the signature and the signed message alone, any verifier can recover the signer’s public key, hash it, truncate it, and obtain the address.

The consequence is the reason a transaction has no separately-trusted from field: the from is derived from the signature, so it cannot lie. If the recovered address is the one whose balance is being spent, the spend is self-evidently authorized — no lookup, no registry, no trust.

This page also introduced the third consensus-relevant detail: EIP-155 replay protection. Early Ethereum signatures did not commit to which chain they were for, so a transaction signed on one network was equally valid on a fork or a testnet — a “replay.” EIP-155 folded the chain ID into the value that gets hashed and signed (encoded through the v byte), so a signature is now valid on exactly one chain. Small change, large payoff: it is what let Ethereum and Ethereum Classic coexist after the 2016 fork without transactions bleeding across.

By the numbers — why guessing the secret is hopeless

   secret keyspace          ≈ 2^256 ≈ 1.16 × 10^77 numbers
   generous attacker: 10^18 guesses/sec × 10^10 machines
                      × 10^10 years (~ age of universe)
                    ≈ 3 × 10^45 guesses
   fraction of keyspace searched ≈ 3×10^45 / 1.16×10^77 ≈ 10^-32

An attacker with absurdly over-generous resources would search a hundred-trillion-trillion-trillionth of the space. Every failure in this part is a failure of the randomness feeding this keyspace — never of the arithmetic protecting it.

The human layer: making a fragile secret survivable

The keystores and mnemonics page confronted the uncomfortable truth underneath all this elegance: the account’s entire existence hangs on 32 raw bytes that are hostile to humans. You cannot memorize them, they are catastrophic to store in plaintext, and — because there is no registrar — there is no reset, no support line, no “forgot my key” flow. Lose them and the account is gone; copy them and the copier is, indistinguishably, you.

Two mechanisms make that survivable:

• Keystores encrypt the private key at rest under a password, using a deliberately slow key-derivation function (scrypt or PBKDF2) so that brute-forcing the password is expensive even if the file is stolen. The keystore is a JSON file you can back up, because on its own it is useless without the password.
• BIP-39 mnemonics map the seed to a 12- or 24-word phrase from a fixed 2048-word list. The words are a human-friendly, checksummed encoding of entropy from which a whole tree of keys is derived (BIP-32/44 hierarchical deterministic wallets). One phrase backs up every account in the wallet, and words are far easier to transcribe onto paper or steel — and to check — than raw hex.

Neither mechanism weakens the cryptography; both sit around it, turning an unmemorable, unforgiving secret into something a person can store, back up, and recover — while preserving the hard rule that possession of the secret is the only thing that matters.

It actually happened — the Parity multisig freeze (November 2017)

Not every loss is a stolen secret. In November 2017 a user triggered a bug in a shared Parity multisig library contract, becoming its owner and then invoking selfdestruct on it. Because roughly 500+ deployed multisig wallets delegated their logic to that one library, destroying it bricked all of them at once — an estimated ~514,000 ETH permanently frozen, with no key that could ever move it. The lesson sharpens this part’s rule: on Ethereum there is no reset. Control is a mathematical fact, and when the mechanism that would let you exercise control is destroyed or lost, no one — no admin, no foundation, no court order the protocol recognizes — can restore it.

Two choices that make Ethereum Ethereum

If you retain nothing else, retain the two places where this part deliberately parted ways with Bitcoin, because both echo through every later part:

1. Original Keccak-256, not SHA-3. The hash that turns a public key into an address (and hashes everything else in Ethereum) is the pre-standardization Keccak. It is not interchangeable with SHA3-256; picking the wrong one silently produces wrong addresses and wrong hashes everywhere.
2. (v, r, s) recovery instead of (r, s) verification. The extra recovery byte lets the signer’s address be reconstructed from the signature alone, so a transaction needs no trusted from. EIP-155 then folds the chain ID into what is signed, so a signature is valid on exactly one chain.

Everything else in the pipeline — a random secret, a one-way curve multiplication, a hash, a truncation — Ethereum inherited unchanged. These two choices are where it put its own stamp.

Handing off: keys become identities

This part built the identities. It deliberately left the rest for later: what a transaction actually contains (its fields, nonce, and the exact bytes that get hashed and signed), what an action costs (gas and fees), and how contract accounts — addresses with code and storage but no keypair — behave once the EVM starts executing.

Keep the atom of this part in view as you go forward. A valid signature over a transaction, recovering to the address whose state is being changed, 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 smallest unit of trustless agreement, and the parts that follow — transactions, gas, the EVM, and consensus — are all built on top of it. From here on, when you read “the sender,” hear what this part proved it really means: the address a valid signature recovered to.

If you have been following the companion ethmini crate, this is the moment its honest shortcut comes due. To stay small, ethmini 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 instead of Keccak-256 (its own Address type keeps the real 20-byte shape but owns up to the substituted hash). This part is exactly the cryptography that stand-in abbreviates. With that unpacked, the next part can treat an address as a settled thing and get on with the question of what it costs to change the world computer’s state.

Check your understanding

1. Recite the full spine from a random secret to an address, naming the operation at each of the three arrows. Which direction is one-way, and why does that make publishing your address safe?
2. Ethereum’s keccak256 and the standardized SHA3-256 produce different digests for the same input. Why, and what practical bug does confusing them cause?
3. What does the v in a (v, r, s) signature let any verifier do, and why does that mean an Ethereum transaction needs no separately-trusted from field?
4. EIP-55 and EIP-155 are both small additions with consensus- or safety-relevant effects. State what each one protects against.
5. A keystore and a BIP-39 mnemonic both address the same underlying problem. What is that problem, and how does each mechanism help — without weakening the cryptography?

Show answers

1. secret →(elliptic-curve multiplication on secp256k1)→ public key (a point) →(Keccak-256 hash)→ 32-byte digest →(keep the last 20 bytes)→ address. Going down is one-way — the curve multiplication and the hash cannot be run backwards — so publishing the address reveals nothing about the secret behind it.
2. Ethereum shipped with the original Keccak submission; NIST later changed the padding rule when finalizing SHA-3 (FIPS 202, 2015). Same input, different padding, different digest. Confusing them means calling sha3_256 where keccak256 was required (or vice versa), which produces valid-looking but wrong hashes and therefore wrong addresses.
3. The v byte lets a verifier recover the signer’s public key — and thus address — from the signature and message alone. Because the address is recovered rather than asserted, the transaction’s from is derived from the signature and cannot lie, so no separately-trusted sender field is needed.
4. EIP-55 mixes the case of an address’s hex letters as a checksum, so a conforming wallet detects a mistyped address and refuses to send funds into the void. EIP-155 folds the chain ID into what is signed, so a signature is valid on exactly one chain and cannot be replayed on a fork or another network.
5. The problem: an account depends entirely on 32 unmemorable, unforgiving bytes, with no reset if lost and total compromise if copied. A keystore encrypts the key at rest under a password using a slow KDF, so the file can be backed up yet is useless if stolen. A BIP-39 mnemonic encodes the seed as a checksummed 12/24-word phrase that is easy to transcribe and back up, and from which a whole tree of keys derives. Both sit around the cryptography — they store and protect the secret; they never weaken it.