Anatomy of a Wallet

BIP32 defines a tree structure for key derivation. Starting from a master key (derived from the BIP39 seed via HMAC-SHA512), child keys are generated at each level using the parent key and a 32-bit index.

Normal vs. Hardened Derivation

Each level in the tree can produce 231 normal child keys (indices 0 to 2³¹-1) and 231 hardened child keys (indices 2³¹ to 2³²-1, denoted with ').

• Normal derivation — uses the parent public key + chain code. Allows deriving child public keys from an xpub without the private key.
• Hardened derivation — uses the parent private key + chain code. Prevents child key compromise from propagating upward to the parent.

Hardened derivation (indicated by an apostrophe, e.g., m/44') creates a cryptographic firewall between tree levels. If a child private key and its chain code are both leaked, hardened derivation prevents the attacker from computing the parent private key. This is critical for multi-account security isolation.

The Derivation Function

Bitcoin historically uses the secp256k1 elliptic curve with ECDSA (Elliptic Curve Digital Signature Algorithm) for transaction signing. The Taproot upgrade (BIP340) introduced Schnorr signatures as an alternative.

ECDSA Signing Process

1. Generate a random nonce k (using RFC 6979 deterministic nonce generation)
2. Compute point R = k × G (elliptic curve point multiplication)
3. Compute r = R.x mod n
4. Compute s = k-1(hash + r × privateKey) mod n
5. The signature is the pair (r, s)

The fundamental security primitive is the Elliptic Curve Discrete Logarithm Problem (ECDLP) — given P = k × G, computing k from P and G is computationally infeasible.

Schnorr Signatures (BIP340)

Schnorr signatures offer several advantages over ECDSA:

• Linearity — signatures can be aggregated (key aggregation for multi-sig looks like a single signature on-chain)
• Provable security — security reduction directly to the discrete logarithm problem
• Smaller and faster — 64-byte signatures vs. variable-length DER-encoded ECDSA
• Batch verification — multiple signatures can be verified faster than individually

An extended public key (xpub) encodes the public key together with its chain code, enabling the derivation of all normal child public keys without access to any private key. This enables powerful use cases:

• Watch-only wallets — monitor balances and generate receiving addresses without spending capability
• Payment servers — an e-commerce backend can generate a unique address for each customer using the xpub, while the private key stays offline on a hardware wallet
• Auditing — share your xpub with an accountant for tax reporting without granting spending access
• Multi-device setups — a phone watches balances while a hardware wallet handles signing

Serialization Prefixes

Extended keys are Base58Check-encoded with version bytes. The familiar ypub/zpub labels are SLIP-0132 wallet conventions that communicate an intended script family; they are not prefixes defined by BIP49 or BIP84 themselves. A plain xpub alone does not prove which address type a wallet should derive, so preserve the descriptor or derivation metadata with it.

How a wallet tracks and spends funds depends on the underlying blockchain model. The two dominant models are fundamentally different in design:

UTXO Model (Bitcoin, Litecoin, Cardano)

In the Unspent Transaction Output (UTXO) model, there is no concept of a "balance." Instead, your wallet scans the blockchain for unspent outputs assigned to your addresses. To spend, you consume one or more UTXOs as inputs and create new outputs:

• Each UTXO can only be spent once and in full
• If the UTXO exceeds the payment amount, the wallet creates a change output back to itself
• Transaction fees are implicit: fee = sum(inputs) - sum(outputs)

Account-Based Models (Ethereum, Solana, BNB Chain)

Account-based chains maintain state associated with accounts rather than consuming UTXOs. Ethereum and BNB Chain use a sequential transaction nonce for each externally owned account. Solana also uses accounts, but transaction freshness and replay protection normally rely on a recent blockhash (or a durable nonce account), not an Ethereum-style per-address transaction counter.

• Simpler mental model — just "balance minus amount"
• No change outputs needed
• Replay protection is chain-specific: sequential account nonces on Ethereum-like chains; recent blockhashes or durable nonce accounts on Solana

Bitcoin supports multiple address types, each corresponding to a different script template that defines the spending conditions:

P2PKH (Pay-to-Public-Key-Hash)

The original Bitcoin address format. The locking script requires a signature and public key that hashes to the specified value. Addresses start with 1.

P2SH (Pay-to-Script-Hash)

Allows arbitrary spending conditions encoded in a script. The sender only needs the hash of the script — the full script is revealed at spending time. This enables multi-sig, time-locks, and other complex conditions. Addresses start with 3.

P2WPKH (Native SegWit)

Segregated Witness version 0. Moves signature data to a separate "witness" structure outside the base transaction, reducing the effective size and thus the fee. Addresses use Bech32 encoding and start with bc1q.

P2TR (Taproot)

The latest address type (SegWit v1), combining Schnorr signatures with MAST (Merkelized Abstract Syntax Trees). A P2TR output can be spent either via a key path (simple Schnorr signature) or a script path (reveals only the executed branch of a script tree). Addresses use Bech32m encoding and start with bc1p.