Public Key vs Private Key: What Each One Actually Does

A crypto wallet does not hold coins. It holds a number — or the words that can regenerate that number — and every rule about self-custody follows from how that number is used.

The difference between a public key and a private key explains most of it: why a signature can prove ownership without giving anything away, why an address is not the same thing as a key, and why a single screenshot of a recovery phrase can empty a wallet years later.

What a Private Key Actually Is

A private key is a number, and a very large one. On Bitcoin and Ethereum it is a 256-bit integer drawn at random from a range that begins at 1 and ends just below the order of the secp256k1 curve — roughly 1.16 × 10⁷⁷ possibilities. Written in hexadecimal it is 64 characters long.

Because it is only a number, it can be stored in many forms: as text, as a QR code, inside a secure chip, or encoded as a list of words. What matters is function, not format. Whoever knows the number can produce valid signatures for the address it belongs to.

Nothing about a key is inherently personal. Two wallets fed by a weak random source could, in theory, produce the same key. That is why wallet software is careful about entropy, and why hand-rolled key generation is a bad place to save effort.

How the Public Key Is Derived From the Private Key

The step from private to public is multiplication on an elliptic curve. Take the curve's fixed starting point, multiply it by your private key, and the result is a second point on the curve: the public key. Bitcoin and Ethereum both use secp256k1, so the operation is the same on both networks.

The reverse direction is not practical. Going from a crypto public key back to the private key means solving the elliptic-curve discrete logarithm problem, and no published method beats brute force on a 256-bit curve.

That one-way relationship is the entire design. You can publish the public key freely, because publishing it does not expose the number that spends.

What a Signature Proves, and What It Does Not

When you send crypto, your wallet does not transmit the private key anywhere. It hashes the transaction, signs that hash with the private key, and broadcasts the transaction together with the signature. Any node can then check the signature against your public key.

Two useful conclusions follow. A valid signature proves that whoever signed knew the private key at that moment. It does not prove that the signer is the person you assume, that the recipient address is honest, or that the transaction does what the website claims. And a signature does not reveal the key itself: the standard ECDSA scheme produces numbers derived from the key and from a per-signature random value called a nonce, and a correct signature exposes neither.

The nonce is where the design has historically been fragile. If the same nonce is used for two different signatures, the private key can be recovered from those two signatures with straightforward algebra. That is not a thought experiment. A repeated-nonce failure broke the PlayStation 3's signing security in 2010, and a predictable random number generator in an Android Bitcoin wallet in 2013 let attackers derive keys from signatures. Modern wallet libraries derive the nonce deterministically from the message and the key specifically to make this impossible.

Why Your Address Is Not Your Public Key

Addresses exist to make what you share shorter and safer to type. Bitcoin hashes the public key with SHA-256 and then RIPEMD-160 and encodes the resulting 20 bytes — Base58Check for older addresses beginning with 1 or 3, Bech32 for newer ones beginning with bc1. Ethereum takes the last 20 bytes of the Keccak-256 hash of the uncompressed public key and writes them as 0x followed by 40 hexadecimal characters.

In everyday use, this means the crypto public key is rarely the string you paste when someone asks where to send funds. You give an address. With older Bitcoin address types the public key becomes visible on-chain once you spend from that address, which is part of why address reuse is discouraged: a key that has been published is a key that has been published.

Where Seed Phrases Fit In

Most people never see a raw private key. A wallet generates entropy — 128 or 256 bits — and expresses it as 12 or 24 words under the BIP-39 standard. From that seed, BIP-32 describes how one wallet can derive an effectively unlimited tree of key pairs along defined paths, so every account and every receiving address can have its own public key and private key while a single backup restores all of them.

That convenience cuts both ways. The words are not a password you can rotate after a leak. They are the root of the tree. Anyone who reads them can regenerate every private key beneath them, on any wallet software, without needing your device.

Who Holds the Key When You Use an Exchange

On a custodial exchange, the platform holds the keys and signs on your behalf. Your login authorises the platform to act; it is not proof that you control an on-chain key. If the platform freezes withdrawals, the signatures stop, no matter what your balance screen says.

Self-custody reverses that arrangement. A hardware wallet, for example, keeps the key inside a chip that signs internally and never exports it, so the secret stays on the device even when the device is plugged into an infected computer. This is the arrangement behind the well-worn industry line that if you do not hold the keys, you do not hold the coins — a phrase that spread for the simple reason that exchange failures keep demonstrating it.

Extended Public Keys and Watch-Only Wallets

BIP-32 also defines an extended public key, usually shortened to xpub. It is a public key plus the chain code needed to derive every address below it. Hand one to accounting software or a block explorer and it can list balances and history without any ability to spend.

The trade-off is privacy. An xpub does not just expose one address; it exposes the whole family of addresses derived from it, and with them the transaction history attached to each. Treat it as sensitive even though it cannot move funds.

The Mistakes That Actually Cost People Money

Most losses in self-custody are not clever cryptographic attacks. They are exposures.

Typing a private key or recovery phrase into a website, a browser extension pop-up, or a chat with someone claiming to be support. No legitimate support process needs either, and any request for them is an attempt to take the funds.

Photographing a seed phrase, storing it in a notes app, or keeping it in cloud storage in plain text. Encrypted backups and offline copies are a different risk category from a screenshot in a photo library that syncs everywhere.

Signing without reading. The key can remain perfectly safe while a token approval drains an account, because the danger sits in what you authorised rather than in who holds the key.

Assuming a key is only at risk if it has been "hacked". In practice, exposure through phishing and careless storage accounts for far more incidents than any break of the underlying cryptography.

What This Means for Your Own Setup

A few practical habits follow directly from the key mechanics.

Check that the address your wallet displays matches the one you meant to use, at least the first and last few characters. When restoring a wallet, the derivation path matters: the same seed can produce different addresses on different paths, which is why a restored wallet sometimes appears empty until the correct path is selected.

Send a small test amount before a large transfer, especially to a new address or a new chain.

Keep the seed offline, and decide deliberately which device holds the key rather than letting convenience decide for you. The wider habit is simple to state: treat the public key and private key as two halves of one arrangement, share the first only in the form of an address, and never let the second leave the device that holds it.

Finally, a note on the long term. The security of secp256k1 keys and ECDSA signatures rests on mathematical assumptions that a sufficiently large quantum computer would undermine. No publicly demonstrated machine comes close today, and there is no agreed timeline, so the sensible response is to keep an eye on how wallet software adds post-quantum options rather than to act on alarm. For now, the ordinary risks — exposure, phishing, and blind signing — are the ones that actually take money.