How Crypto Wallets Manage Keys Instead of Coins

A crypto wallet does not contain coins. The coins exist as entries on a blockchain, and the wallet stores the private keys that can produce valid signatures for those entries. "Sending coins" therefore means publishing a signed instruction that changes which key is able to sign next.

Key takeaways

Bitcoin records value as unspent transaction outputs (UTXOs); a wallet balance is the sum of those its keys can spend. Ethereum records a balance and a nonce per account.
A private key is a 256-bit number, the public key is computed from it, and most address types are a hash of the public key; each step is easy to compute forward and, as far as is known, impractical to reverse.
A signature proves the signer holds the private key without revealing it, and it covers the transaction details.
A hierarchical deterministic (HD) wallet derives every key from one seed, so one backup restores the whole tree if the same derivation path and passphrase are used.
A watch-only wallet holds public data only: it can see balances and generate addresses, but it cannot sign.

Where the coins actually are

The Bitcoin developer documentation describes the block chain as an ordered, timestamped record of transactions. An input points at a previous output by transaction ID and output index, and an output stays an unspent transaction output (UTXO) until some later input spends it. The same guide notes that wallet software gives the impression that satoshis are sent to and from wallets, while bitcoins really move from transaction to transaction.

Ethereum keeps accounts instead. According to the ethereum.org accounts documentation, each account has a balance (in wei, 10^18 per ETH) and a nonce, a transaction counter that stops a signed transaction from being replayed. An externally owned account (EOA) is controlled by whoever holds its private key; a contract account is controlled by its code.

Feature	Bitcoin	Ethereum
What the ledger stores	Unspent outputs, each locked by a script	Per-account state: balance, nonce, code hash, storage root
What a wallet balance is	Sum of the UTXOs its keys can spend	The balance field of the account's address
What the key controls	The right to spend specific outputs	The right to initiate transactions from the account
Replay protection	An output can be spent only once	Sequential nonce

Illustrative example: a Bitcoin payment from three outputs

Suppose a wallet's keys control three UTXOs of 0.30, 0.25 and 0.10 BTC, a balance of 0.65 BTC. The owner pays 0.40 BTC with a fee of 0.0002 BTC. The wallet picks the 0.30 and 0.25 outputs as inputs (0.55 BTC in total), creates a 0.40 BTC output for the recipient and a change output back to one of its own addresses.

change = inputs - payment - fee
       = 0.55 - 0.40 - 0.0002
       = 0.1498 BTC

After confirmation the two spent outputs are gone, the 0.10 UTXO is untouched, and the new change output is added: 0.10 + 0.1498 = 0.2498 BTC, which equals 0.65 minus the payment and the fee. No "coin" moved between containers: the transaction retired two ledger entries and created two new ones.

From private key to address

Bitcoin uses elliptic-curve cryptography on the secp256k1 curve. The developer guide states that a private key is 256 bits of random data, from which the public key is derived deterministically. Ethereum signs on the same curve, as EIP-155 shows.

The address is a further step, and the formats differ:

Bitcoin, original format (P2PKH). The output is locked to a public key hash, commonly written as HASH160 (SHA-256 followed by RIPEMD-160, 20 bytes). The developer guide says hashing shortens the key and guards against possible future key-reconstruction attacks; the address adds a version number and a checksum.
Bitcoin, native SegWit (P2WPKH). BIP 141 defines a version 0 witness program of 20 bytes as the HASH160 of the public key. BIP 173 encodes it in bech32 with the prefix "bc" and a six-character checksum, giving addresses of 2 + 1 + 1 + 32 + 6 = 42 characters; the checksum is guaranteed to catch any error affecting at most 4 characters.
Bitcoin, Taproot. A version 1 output carries a 32-byte x-only key directly rather than a hash, and BIP 350 says witness versions 1 and higher use the bech32m variant, which changes only the checksum. The 32-byte program makes these addresses 62 characters long.
Ethereum. The address is the last 20 bytes of the Keccak-256 hash of the public key with 0x in front, a 42-character hex string. EIP-55 adds an optional checksum by capitalizing some letters (see the FAQ).

Two different one-way steps are involved. A hashed address does not reveal its public key until the output is spent (a Taproot output carries the key itself). Getting from a public key back to the private key is a separate problem: no practical way to reverse the elliptic-curve step is known, and the developer guide lists reconstructing private keys from public keys only as a hypothesized future attack.

How a signature proves control

The developer guide explains that the original Bitcoin signature is made by combining transaction data with the private key, using ECDSA. The signed data includes the previous transaction ID and output index, the old and new pubkey scripts, and the amount. Nodes check the signature against the public key, and for hashed outputs check that the key hashes to the stored value. The private key is never transmitted, and because the amount and destination are inside the signed data, altering either afterwards breaks the signature under the default signing mode.

Taproot changed the scheme. A Taproot key-path spend carries a 64-byte BIP 340 Schnorr signature (65 bytes if an explicit signature-hash type is added); activation on mainnet came at block height 709,632. BIP 340 keys are 32 bytes, against the earlier 33-byte compressed encoding. On Ethereum, the signature is what identifies the sender, and the account's nonce sits inside the signed transaction.

One seed, a whole tree of keys

Older Bitcoin Core wallets pre-generated a pool of independent keys, and backups had to be repeated by hand to capture new ones. Hierarchical deterministic wallets removed that burden. Under BIP 32, a seed of 128 to 512 bits (256 advised) is run through HMAC-SHA512 to produce a master private key and chain code, and every child key is computed from its parent, an index and the chain code. The developer guide calls the root seed the only data a user needs to back up to recover every derived key.

BIP 39 turns the seed into words. The wallet appends a checksum of ENT/32 bits to the entropy and reads the result in 11-bit groups, one word from a 2,048-word list per group. The words and an optional passphrase then pass through PBKDF2 with HMAC-SHA512 and 2,048 iterations to produce a 512-bit seed.

Entropy (bits)	Checksum (bits)	Words	Calculation
128	4	12	(128 + 4) / 11 = 12
192	6	18	(192 + 6) / 11 = 18
256	8	24	(256 + 8) / 11 = 24

BIP 44 fixes the layout of the tree with a five-level path:

m / purpose' / coin_type' / account' / change / address_index

BIP 44 sets the purpose to 44' and Bitcoin's coin type to 0'; the change level separates receiving (0) from change (1) addresses, and the apostrophe marks hardened derivation. Later proposals reuse the same structure with a different purpose: BIP 84 uses 84' for native SegWit (bc1q) addresses and BIP 86 uses 86' for single-key Taproot. During a restore, BIP 44 has software scan the receiving chain of each account, stop after 20 unused addresses in a row, and stop opening new accounts once it reaches one with no transactions.

How big the key space is

A private key is any integer from 1 up to one less than the curve order n, which BIP 32 uses as its validity limit; n is just under 2^256. The sizes, computed in Python:

2^256 = about 1.158 x 10^77 possible keys
2^160 = about 1.462 x 10^48 possible 20-byte addresses
2^128 = about 3.403 x 10^38 possible 12-word phrases (128 bits of entropy)

A 12-word phrase is 12 × 11 = 132 bits, 4 of them checksum. The 512-bit seed that comes out of PBKDF2 is a function of the words and passphrase, so it holds no more entropy than those inputs.

Watch-only wallets

BIP 32 allows public-only derivation for normal (non-hardened) children: an extended public key (xpub) lets software compute child public keys without any private key. The developer guide notes that this lets a key-distribution program run on a possibly insecure web server, provided it tracks which keys it has handed out so addresses are not reused.

The result can list addresses, watch incoming outputs and build unsigned transactions while signing happens elsewhere. The guide describes this split between a networked wallet and a signing-only wallet, either offline or a hardware device that shows transaction details on its own screen.

One caveat comes from BIP 32 itself. An xpub together with any non-hardened child private key is equivalent to the parent's extended private key. Because BIP 44 hardens the account level, such a leak stays within one account.

What sending to a wallet changes

When a Bitcoin transaction creates an output for that address, it creates a lock that can be opened only by a signature from the matching private key. When an Ethereum transfer succeeds, the sender's balance falls by the amount plus the gas fee and the recipient address's balance rises by the amount. In both systems, what changes is which key can produce the next valid signature.

So two wallet apps loaded with the same seed, derivation path and passphrase show the same funds: they derive the same keys and read the same ledger. A wallet app is a viewer and signer, not a vault.

Frequently asked questions

Does a smart contract wallet have a private key?

A contract account on Ethereum does not. The ethereum.org documentation states that contract accounts have no private keys and are controlled by their code. Whatever authorizes actions on a contract is written into its code, often by checking a signature from an ordinary key.

Is a 12-word phrase much weaker than a 24-word one?

The 12-word phrase carries 128 bits of entropy and the 24-word phrase 256 bits, per the BIP 39 table. At an assumed, hypothetical rate of 10^12 guesses per second, trying all 2^128 phrases would take about 1.1 × 10^19 years (2^128 divided by 10^12 per second, then by 31.56 million seconds per year). At that rate, the gap between the two lengths has no practical effect on brute-force guessing.

Why does a restored wallet sometimes show a zero balance?

A common cause is the passphrase. BIP 39 notes that every passphrase generates a valid seed, so a missing or mistyped passphrase opens a different, empty wallet. Other causes come from the scan: funds beyond the 20-address gap, or under a different purpose (44', 84', 86') or coin type than the wallet checks, will not appear until it is pointed there. The keys still exist; the software is looking in the wrong part of the tree, or in a different tree.

Does an address reveal the public key?

For hashed address types it does not, until the output is spent: the spender then supplies the full public key alongside the signature. From that point the key is public, so reusing the address no longer has the protection of the hash. Taproot outputs show the 32-byte key from the start.

Why are some Ethereum addresses written with mixed capitals?

That is the EIP-55 checksum. Whether each letter a to f is capitalized depends on a Keccak-256 hash of the lowercase address, so a wallet can reject most mistyped addresses; the proposal puts the chance of a random typo passing at about 0.0247%. Software that ignores case still reads the address correctly.

Checking a wallet's key model

Check whether the wallet derives keys from a seed (BIP 32/39), which derivation path it uses and whether a passphrase was set, so a restore in other software rebuilds the same tree.
Note whether the wallet is full-service, signing-only or watch-only, which tells you where the private keys actually sit.
Compare an address's format with the type in the table above (the 42-character "bc1q" form, the 62-character "bc1p" Taproot form, or a 0x address) before sending anything, using a small test transfer if the stakes warrant it.
Treat the seed phrase and any passphrase as the secrets everything else follows from: whoever holds them can rebuild every key in the tree.