Public & Private Keys Explained (Wallet Addresses, Seed Phrases, Signatures)

1) Private key → Public key → Address (mental model)

Most modern chains use public-key cryptography. On Ethereum-style chains, a private key is a 256-bit random number. Using elliptic-curve multiplication (secp256k1 on Ethereum/Bitcoin), you derive a public key. From that, the wallet computes a short, shareable address (e.g., on Ethereum: Keccak-256 of the uncompressed public key, last 20 bytes, prefixed with 0x). Anyone can send value to your address. Only someone who knows the private key can produce a valid digital signature to move funds.

// Ethereum mental model (high-level)
privateKey = random256()
publicKey  = secp256k1_multiply(privateKey)
address    = keccak256(publicKey_uncompressed)[12:]  // last 20 bytes
assert(!feasible(publicKey → privateKey))            // one-way

Sources: Ethereum.org — Accounts, Elliptic Curve (secp256k1) primer.

2) Entropy & secure key generation

A private key is only as strong as its randomness (entropy). Good wallets use secure OS random number generators (RNGs) or hardware true RNGs. “Brain wallets” (phrases you invent) are risky because humans are predictable and attackers precompute dictionaries.

• Do: Use reputable wallets (hardware wallets preferred). Let the device generate keys internally.
• Don’t: Hand-craft keys or mnemonics. Avoid shady vanity address generators.
• Consider: Extra passphrase over BIP-39 seed (advanced; see below).

References: BIP-32, BIP-39, Ethereum.org — Wallets.

3) Seed phrases & HD wallets (BIP-39 / BIP-32 / BIP-44)

Modern wallets are hierarchical deterministic (HD). You back up one mnemonic — a 12 or 24-word seed phrase (BIP-39). That mnemonic deterministically derives a master seed from which a tree of keys is generated (BIP-32). BIP-44 then standardizes the path structure so wallets can interoperate across coins and accounts.

// Typical ETH account derivation examples
m/44'/60'/0'/0/0     // First account
m/44'/60'/0'/0/1     // Second account
m/44'/60'/1'/0/0     // Second "account" (different branch)

Sources: BIP-39, BIP-32, BIP-44.

4) Derivation paths & multi-account hygiene

Because one seed can generate endlessly many accounts, you should plan naming and hygiene. Keep a “hot” account for daily activity, separate from your long-term “vault”. If you migrate wallets, ensure they agree on derivation paths; otherwise you may think funds are “missing” when the new wallet simply looks at a different branch.

• Label accounts in your wallet and explorer (e.g., “Daily”, “DeFi-LP”, “Vault”).
• Document derivation paths for future recovery or audit.
• Rotate addresses for privacy where appropriate (Bitcoin best-practice; less common on ETH due to UX).

5) What a signature really is (EIP-155, EIP-712, EIP-1271)

When you press Confirm in a wallet, it builds a canonical message from the transaction fields (or typed structured data) and signs the digest with your private key (ECDSA over secp256k1 on Ethereum). Nodes verify the signature using your public key. If valid, protocol rules allow the state update.

// High-level signing flow
digest     = keccak256(rlpEncode(txFields with chainId))
signature  = sign(digest, privateKey)  // yields (v, r, s)
valid      = verify(signature, digest, publicKey)
if (valid) include tx in block → state changes

6) Address formats & checksums (ETH vs Bitcoin vs Solana)

Ethereum: addresses are the last 20 bytes of Keccak-256 hash of the uncompressed public key (no prefix byte), displayed in hex with 0x. EIP-55 suggests a mixed-case checksum that catches typos; some apps always lowercase. ENS names (alice.eth) resolve to addresses on chain.

Bitcoin: uses Base58Check (legacy), bech32 (bc1...) and bech32m for segwit/taproot with built-in checksums; addresses depend on script types (P2PKH, P2SH, P2WPKH, P2TR). Bitcoin whitepaper, BIPs.

Solana: uses Ed25519 keys; addresses are Base58 encodings of public keys. Different curve, different encoding — and not interchangeable with ETH/BTC.

7) Wallet types: hot, cold, custodial, smart wallets

See: Ethereum.org — Wallets, vendor docs: Ledger, Trezor.

8) Key management best practices (2025 edition)

9) Recovery, rotation & disaster planning

Incidents happen. Good setups fail gracefully. Prepare for theft, device loss, or house fire before they occur.

10) Top threats: phishing, drainers, approvals, malware

Most losses are social-engineering, not cryptography. Attackers trick you into signing malicious approvals or revealing seeds.

Read: Ethereum.org — Security, vendor guidance: Ledger, Trezor.

11) Playbooks: personal, creator, and team setups

12) Reading explorers & verifying what you sign

Explorers like Etherscan let you audit what happened on-chain and what you’re about to sign off-chain.

• Address page: balances, tokens, approvals, ENS names.
• Transaction page: status, gas, method, event logs, decoded inputs.
• Contract page: verified source, ABI, read/write tabs (simulate before write).

See: Ethereum.org — Transactions.

13) Gentle cryptography: why one-way works

Elliptic-curve cryptography relies on the hardness of the discrete logarithm problem: given a point G and a public point P = kG, finding k is computationally infeasible with present knowledge. Ethereum/Bitcoin use the secp256k1 curve. Signatures (ECDSA) are constructed so that anyone with the public key can verify that the signer knew the private key at signing time.

// ECDSA verification sketch
Given (msgHash, signature(v,r,s), publicKey)
1) Compute a candidate point from (r, s, msgHash)
2) Check curve equations and recovery id v
3) Accept if derived publicKey matches and equations hold

References: secp256k1 primer, Bitcoin Whitepaper.

14) Common myths & mistakes

• Myth: “My exchange login is my wallet.”
  Reality: That’s custodial access. If they lock you out, you’re out.
• Mistake: Emailing or photographing the seed phrase.
  Fix: Keep offline; use metal backup for longevity.
• Myth: “I know my address, so I can recover.”
  Reality: You must have the private key/seed.
• Mistake: Unlimited token approvals to unknown contracts.
  Fix: Minimal allowances; schedule revokes.
• Myth: “Higher gas makes a failing tx succeed.”
  Reality: Gas can’t fix logical reverts; simulate first.

15) References & further learning

• Ethereum.org — Wallets Overview
• Ethereum.org — Transactions
• EIP-155, EIP-712, EIP-1271
• BIP-39, BIP-32, BIP-44
• Elliptic Curve (secp256k1) primer
• Bitcoin Whitepaper
• Ledger Support • Trezor Learn
• OWASP Top 10 (general app-sec hygiene)
• Cyfrin Updraft — security-minded smart contract training

16) Mini-FAQ

Is a seed phrase the same as a private key?

No. A seed phrase (BIP-39) can deterministically generate many private keys. A private key controls exactly one account.

Can someone guess my private key from my address?

Not with current computing. The derivation is designed to be one-way and computationally infeasible to reverse.

What’s the simplest safe setup?

Hot wallet (small balance) + hardware wallet (holdings), with seed backed up on metal in two places, and periodic approval revokes.

Will account abstraction replace seed phrases?

Smart wallets may hide seeds from users and offer social recovery, but keys still exist under the hood. UX is improving, not removing cryptography.

Quick check

1. How do a private key, public key, and address relate?
2. What problem does EIP-712 solve? Why does it matter for phishing?
3. Why can importing the same seed into two wallets show different addresses?
4. Name two reasons to keep a hot wallet separate from a vault wallet.

Next up: turn this knowledge into safety. Learn how to configure hardware wallets, revoke risky approvals, and simulate transactions.