Library
Mastering Ethereum: Building Smart Contracts and DApps · 15 of 15
Mastering Ethereum: Building Smart Contracts and DApps
blockchain HIGH

Wallets & Key Management — HD Wallets, Mnemonics & Self-Custody

Mastering Ethereum: Building Smart Contracts and DApps Andreas M. Antonopoulos & Gavin Wood
wallets bip-39 bip-32 bip-44 mnemonic hd-wallet self-custody

Key Principle

A wallet is "the system used to store and manage a user's keys" — a keychain of private/public pairs, not a money store (Chapter 5). Ether and tokens live on-chain; the wallet only holds the keys that authorize moving them. This inverts banking: on Ethereum everyone can see an account's balance and everyone must be convinced (by a signature) the owner authorized a move. There is no custodian and no undo — losing the keys loses the funds and contracts, forever (Chapter 5).

The wallet design progression — nondeterministic → deterministic → hierarchical — is a progression in how few secrets you must protect and how recoverably.

Why This Matters

Privacy best practice demands a fresh address per transaction; reusing one key lets anyone correlate all your activity on the public ledger ("a privacy nightmare"), but a fresh key per use is unmanageable to back up (Chapter 5). Good wallet design resolves this tension, which is exactly what deterministic wallets achieve:

  • Nondeterministic (JBOK, "Just a Bunch of Keys"): each key independently random and unrelated. Every new key is a new thing to back up; a backup taken before the latest key is generated does not protect funds sent to it. Loss-before-backup is the default failure mode (Chapter 5). "The use of nondeterministic wallets is discouraged for anything other than simple tests" (Chapter 5).
  • Deterministic / HD: all keys derive from one seed as a tree, so "a single backup, at creation time, is sufficient to secure all the funds and smart contracts in the wallet" (Chapter 5) — enabling fresh-key-per-use privacy without unmanageable backups.

Good Examples

  • BIP-39 mnemonic → seed. A wallet-generated 12–24 word list is the backup, encoding the random number that seeds the whole tree. Generation: random sequence S (128–256 bits) + a SHA-256 checksum, split into 11-bit groups mapped to a 2,048-word dictionary; then PBKDF2 with 2,048 rounds of HMAC-SHA512 (salt = "mnemonic" + optional passphrase) produces the 512-bit seed (Chapter 5). The stretching makes brute-forcing costly; the salt blocks lookup-table attacks and carries the passphrase.
    FCCF1AB3329FD5DA3DA9577511F8F137
wolf juice proud gown wool unfair
wall cliff insect more detail hub
  • BIP-32 extended keys + hardening. An extended key (xprv/xpub) is a key plus a 256-bit chain code. An xpub derives an entire branch of public-only keys with no private key present — so a web/ecommerce server can hold only the xpub, issue fresh receive addresses, and hold zero spendable keys while the xprv stays offline (Chapter 5). Hardened derivation plugs a leak: without it "a single leaked child private key, together with a parent chain code, reveals all the private keys of all the children... [and] can be used to deduce the parent private key" (Chapter 5). Best practice: always harden level-1 children of master keys. Hardened indices are at/above 2^31 (0x80000000), shown with a prime: 0' = 2^31.
  • BIP-44 path m / purpose' / coin_type' / account' / change / address_index. purpose' = 44'; Ethereum's coin_type' (SLIP0044) = 60'. Example: M/44'/60'/0'/0/2 = the third receiving public key for the primary Ethereum account (Chapter 5). The change level is a vestigial Bitcoin artifact — Ethereum has no change addresses and uses only the receive path (Chapter 5).

Counterpoints

  • Storing the mnemonic electronically. The mnemonic is the wallet — anyone with the words controls all funds and contracts. "Never store it electronically... Write it down on paper and store it in a safe and secure place" (Chapter 5). Keep the seed offline.
  • Confusing a mnemonic with a brainwallet. Brainwallets use user-chosen words; humans are terrible randomness sources, making them weak, and memorization is "a recipe for not having your backup when you need it" (Chapter 5). Mnemonics are wallet-generated from real entropy.
  • Mishandling the optional passphrase. Every passphrase yields a different valid seed ("there are no 'wrong' passphrases") (Chapter 5). A forgotten passphrase = permanent loss; storing it beside the seed makes it pointless. It needs a planned recovery path, or it converts a security feature into a single point of loss.
  • Encrypting the key directly with the passphrase. Keystores instead run a KDF (e.g. scrypt, n: 262144 rounds) to stretch the passphrase, imposing a fixed per-guess cost so brute-force/dictionary/rainbow-table attacks must run all rounds every attempt (Chapter 5). Without stretching, a weak passphrase falls instantly.

Key Quotes

"the seed is sufficient to recover all the derived keys, and therefore a single backup, at creation time, is sufficient to secure all the funds and smart contracts in the wallet." — Antonopoulos & Wood, Chapter 5

"The use of nondeterministic wallets is discouraged for anything other than simple tests... use an industry-standard–based HD wallet with a mnemonic seed for backup." — Antonopoulos & Wood, Chapter 5

Rules of Thumb

  • Build any new wallet as the industry-standard stack: BIP-39 (mnemonic) + BIP-32 (HD tree) + BIP-43 (purpose) + BIP-44 (multicurrency), so a mnemonic exported from one wallet imports into another.
  • Back up the mnemonic on paper, never digitally; treat it as the single ultimate secret.
  • Use an Ethereum-aware BIP-39 implementation (coin_type 60'); BIP-32 derivation is shared across coins, only address encoding differs.
  • For receive-only servers, deploy an xpub and harden level-1 children — never expose the xprv.
  • [DATED 2018: derive keys only on hardware wallets / air-gapped, never a web page even offline. ERC-4337 account abstraction now offers smart-contract wallets and social recovery, addressing the seed-loss single-point-of-failure this chapter treats as unavoidable.]

Related References