Private keys, public keys and seed phrases: what actually controls your bitcoin

A private key authorizes the spending conditions that use it

A Bitcoin private key is a secret scalar used to produce signatures, commonly encoded in 32 bytes. A signature can satisfy spending conditions involving the corresponding public key, but an output may require additional keys or other conditions.

A deterministic wallet can derive many keys from a seed, with extended keys and derivation paths describing the hierarchy. The way the wallet encodes or stores a key does not replace the output’s actual authorization conditions.

Losing or exposing a key has consequences determined by that policy. One missing key can prevent a single-key spend, while a threshold arrangement may retain another authorized recovery path. An attacker still needs enough authority to satisfy the actual script.

A public key comes from the private key, and the trip is one way

From the private key, the wallet computes a public key using elliptic curve mathematics on a curve called secp256k1. The Bitcoin Wiki describes it as “the parameters of the elliptic curve used in Bitcoin’s public-key cryptography,” defined in the Standards for Efficient Cryptography, with the equation y² = x³ + 7. You do not need the equation to use Bitcoin. What matters is the shape of the operation: multiplying a fixed starting point on the curve by your private key gives a public key, and there is no known practical way to run that multiplication backwards.

A public key lets others verify signatures made with the corresponding secret. Public information can still reveal transaction relationships. Receiving addresses encode supported payment destinations; different address types can refer to public-key material or script commitments rather than all being the same hash format.

The wiki notes two reasons the curve was chosen. Its constants “were selected in a predictable way, which significantly reduces the possibility that the curve’s creator inserted any sort of backdoor,” and its structure allows implementations that are “often more than 30% faster than other curves.” A point on the curve, which is what a public key is, takes 33 bytes to write in compressed form or 65 bytes uncompressed.

Match the backup to the wallet’s derivation rules

BIP-39 first normalizes the mnemonic and optional passphrase using Unicode NFKD, then derives a seed. A different normalized passphrase derives a different seed without a built-in correct-passphrase signal. A wallet-file password is a separate encryption mechanism.

Recovering the intended outputs also requires the relevant derivation paths and script conventions. A descriptor can preserve this context. For multisignature arrangements, one participant’s seed does not automatically replace the other keys or the policy information.

One seed grows a whole tree of keys

BIP-32 derives a master extended key from a seed and derives child keys along a hierarchy. An extended private key can derive descendants within its branch. An extended public key can derive only non-hardened public descendants and does not contain ordinary signing authority.

A public export can expose a branch’s past and future activity. BIP-32 also describes how a parent extended public key combined with a corresponding non-hardened descendant private key can expose the parent private key. Read-only information is therefore not necessarily harmless to share.

BIP-44 specifies one wallet hierarchy: hardened purpose, coin-type and account levels, followed by receiving/change and address-index levels. Its account-discovery process uses a 20-unused-address gap limit on the external chain. Other wallet policies can use different paths or scripts, so a seed alone does not identify every recovery convention.

“Not your keys, not your coins,” said plainly

The saying gets repeated so often it can sound like a slogan. Read literally, it is a description of where the risk sits. If a company holds the private keys, what you have is a claim on that company, recorded in its database. The bitcoin.org security page says the same thing without the rhyme: “When a third party controls your keys, you rely entirely on their security and honesty,” and “history has shown that exchanges and online wallets can be hacked, fail, or freeze access to funds.”

The site’s dossier on the collapse of Mt. Gox is the long version of that sentence. Customers had balances; the company had the keys; when the company could no longer honor withdrawals, the balances became claims in a bankruptcy. That is not an argument that everyone must hold their own keys. Holding them yourself means there is no one to call if the phrase is lost or a device is compromised. It is an argument for knowing which arrangement you are in.

Check who can authorize an on-chain spend and what the documented recovery process restores. The ability to reset an application password alone does not establish who controls the signing keys. Custody and recovery need to be evaluated from the actual arrangement.

A seed is only one part of a recovery plan

BIP-39 applies Unicode NFKD normalization to the mnemonic and optional passphrase before deriving the seed. A different normalized passphrase derives a different valid seed without a built-in indication of which wallet was intended.

Recovery also requires compatible derivation paths and script types. Imported keys, multisignature policies and cosigner information may need separate backups. The relevant wallet documentation determines the complete recovery procedure.