Public and Private Keys: Cryptography Explained Simply

A public and private key form a matching pair of numbers. The private key is a secret random number you use to sign transactions. The public key is calculated from it and anyone may see it: the whole network uses it to check your signature. Going from the private to the public key is easy; going back is beyond any computer that exists today. The ownership of every bitcoin rests on this one-way street.

The key pair: letterbox and seal

Two pictures help before the first formula.

The letterbox. Your address is like a letterbox with a slot. Anyone can drop something in, that is, send you bitcoin. Only the person with the key to the box can take it out. The slot is public, the key private.

The seal. People used to seal letters with a signet ring. Everyone knew the imprint and could check whether a seal was genuine. Only the person holding the ring could make one. In Bitcoin the private key is the ring, the public key the known imprint, and the signature the seal on one particular transaction.

The seal is the better picture, because Bitcoin encrypts nothing. Every transaction sits openly in the blockchain. Cryptography here is not about secrecy but about authenticity: only the owner of the private key can produce a valid signature, and anyone can check it without ever seeing the private key.

This principle is called asymmetric cryptography or public-key cryptography. Asymmetric, because the two keys do different jobs. A password or a safe combination works differently: whoever checks that the code is right has to know the code. In Bitcoin tens of thousands of nodes check every signature, and none of them may know your key. With a password that would be impossible.

How a random number becomes a public key

It starts with a number. Your wallet picks a number between 1 and just under 2²⁵⁶. That is the private key. It has no special form, is not a password and contains nothing about you. Written in the usual hex notation it is 64 characters from 0–9 and a–f.

From that number the wallet calculates the public key. Bitcoin uses an elliptic curve called secp256k1 for this, defined in the SEC 2 standard of the Standards for Efficient Cryptography Group. Picture the curve as a huge but finite set of points on which points can be "added". One of these points is agreed by everyone in advance: the starting point G.

The public key is the starting point added to itself as many times as the private key says. If your private key were 5, your public key would be G + G + G + G + G. For a 77-digit number the wallet doesn't do this step by step but takes a shortcut: it keeps doubling and adds where needed. Around 256 doublings are enough, which takes a fraction of a second.

The way back has no such shortcut. Someone who sees only the point doesn't know how often G was added. They would have to guess. This is called the elliptic curve discrete logarithm problem, and for curves of this size nobody knows a fast way to solve it, except with large quantum computers that don't exist yet.

Why nobody guesses your private key

The number of possible private keys is hard to imagine: about 10⁷⁷, a 1 followed by 77 zeros. Common estimates put the number of atoms in the observable universe at about 10⁸⁰. There are almost enough keys for one per atom.

An attacker could generate random keys and check whether the matching address holds a balance. This fails not on patience but on physics. The worked example shows why.

That leads to the first practical point: your key is only as strong as the randomness it comes from. A wallet with a good random number generator, or dice in your hand, gives you 256 bits. A sentence you made up and hashed into a key gives far less. Such "brain wallets" were emptied by the thousand in the years after 2011, as attackers ran through quotes, song lyrics and password lists.

Digital signatures: what they prove and what they don't

When you send, your wallet signs the transaction with the private key. Nodes check the signature with the public key. How the rest of a transaction is built, with inputs, outputs and change, is explained in How does a Bitcoin transaction work?.

A valid signature proves three things at once:

1. Ownership: the signer knows the private key belonging to this public key.
2. Consent: they signed exactly this transaction, with this amount and this recipient.
3. Integrity: if anyone changes a single bit afterwards, the signature no longer fits.

What it does not prove: who the person behind the key is. Whether you, an heir or a thief signs makes no difference to the network. A signature is not encryption either. Anyone reading the blockchain sees the amount, the recipient and, once you spend, your public key.

Bitcoin has two signature schemes on the same curve: ECDSA since 2009 and Schnorr since the Taproot upgrade in November 2021. Schnorr signatures are shorter and can be combined, so that several keys produce one joint signature. The formulas and what this means for multisig are in Taproot and Schnorr.

Randomness in the signature: when it fails, the key is gone

Besides the private key, every signature needs a second secret number, the nonce. It must be fresh and unpredictable for each signature. If the same nonce is used with the same key for two different messages, anyone can calculate the private key from the two public signatures. That takes no computing power, just a line of school algebra.

This is not just theory. Two cases are well documented:

• Sony PlayStation 3, 2010: Sony signed software with ECDSA, but always with the same nonce. The hacker group fail0verflow showed at the 27C3 congress in Berlin that Sony's private signing key could be calculated from this.
• Android wallets, August 2013: a flaw in Android's random number generator (SecureRandom) caused Bitcoin wallets on Android devices to repeat nonces. Attackers calculated the private keys and emptied affected addresses. Bitcoin.org published a warning on 11 August 2013; the wallets had to generate new keys and move the funds.

Today good wallets no longer take the nonce from the random number generator alone but calculate it deterministically from the private key and the message (RFC 6979 for ECDSA, a similar method in BIP 340 for Schnorr). The same message gives the same nonce, different messages different ones. The repetition problem disappears.

For you this means: use widely used, maintained wallet software or a hardware wallet, not home-made scripts. The maths of secp256k1 has not been broken since 2009. Losses came from the implementation.

From the seed phrase to thousands of keys

Early wallets created each key separately and stored them all in a file. Anyone who forgot to make a fresh backup lost the new keys. Today every key in a wallet comes from a single source: the seed phrase of 12 or 24 words. How to store it is covered in Storing your seed phrase safely. Here we look at what the wallet does with it.

The path has three stages:

1. Words → seed (BIP 39). The words encode randomness: 12 words stand for 128 bits, 24 words for 256 bits, plus a small checksum. The wallet stretches them with a deliberately slow process into a 512-bit seed. An optional passphrase goes in here; any other passphrase gives a completely different seed.
2. Seed → master key (BIP 32). The seed produces the private master key and a second value, the chain code.
3. Master key → children (BIP 32). With the master key and chain code the wallet calculates child keys, and from these more children, as deep as needed. Each branch has a number; together they form a path.

The result is a tree. It is always the same as long as the words and passphrase stay the same. That is why any compatible wallet restores the same addresses from your 24 words, even years later and from a different manufacturer.

Derivation paths: BIP 84 and BIP 86

So that different wallets use the same branches, there are fixed paths. The number after the m says which address type is meant.

A prime ′ means "hardened". The upper levels are hardened so that a leaked key further down doesn't give away the whole tree. The last two levels are derived normally. That allows a trick which matters in the section on the xpub.

From public key to address

The address you hand out is usually not the public key itself. For bc1q addresses it is a 20-byte hash of it, for bc1p addresses (Taproot) a slightly modified public key. Both are encoded to be human-readable and protected against typos by a checksum. The formats, their fees and how to check before sending are explained in Bitcoin addresses explained.

The chain therefore has three links, and each goes in one direction only:

seed phrase → private key → public key → address

From an address you cannot find the public key, from a public key not the private key, and from a private key not the seed phrase.

The xpub: one public key for a whole account

BIP 32 also has an extended public key, xpub for short (often zpub for SegWit accounts). It consists of a public key and the chain code of one level of the tree, typically the account level m/84′/0′/0′.

Because the lower levels are derived normally, the xpub lets you calculate all public child keys, and so every address of the account, without knowing a single private key. This is useful: the software on your computer can create new receiving addresses and show your balance while the private keys stay in the hardware wallet. In a multisig wallet each device needs the others' xpubs.

Nobody can spend with an xpub. But it is not a harmless value:

• Privacy: whoever has your xpub sees every past and future address of the account, your entire balance and every movement. Give it only to your own software or your own node.
• One child key plus the xpub: if an attacker gets the xpub and a single normally derived private child key, they can calculate the private key of the level above, and with it the whole account. The BIP 32 specification warns about this explicitly. So never export individual private keys from an HD wallet, for instance to import them into another app.

Signing messages: proving ownership to an exchange

Signatures work for more than transactions. Many wallets can sign any text message with the key of an address. Anyone can then check that the signature matches that address.

In the German-speaking countries this has a practical use. In the EU, the Transfer of Funds Regulation (EU) 2023/1113 has applied since 30 December 2024. If you send more than €1’000 from an exchange to your own wallet or the other way round, the exchange must check whether the address belongs to you. In Switzerland, FINMA has required institutions since 2019 to verify ownership of an external wallet before sending to it. Common methods are a signed message, a screenshot of the wallet or a small test transfer (the "Satoshi test").

A signed message does reveal that this address belongs to your identity. So sign only with addresses you are giving the exchange anyway, never with addresses you use for other payments.

What this means for your security

A few simple rules follow from the cryptography.

• The private key and the seed phrase are the same secret. Whoever has the words has every key. No support desk, exchange or wallet app ever needs them. Anyone who asks wants to steal.
• Create keys on a device built for it. A hardware wallet generates randomness, stores the keys and signs without handing them out. The hardware wallet comparison gives an overview.
• Treat the xpub like a bank statement. It opens nothing but reveals everything.
• Check what you sign. The signature covers exactly what the device displays. Read the address and amount on its screen, not on the computer.

One question remains: what if the way back from public to private key is found one day? A large quantum computer running Shor's algorithm could do exactly that. Coins whose public key is already visible, for instance on reused addresses, would be at risk first. How far the technology is as of November 2026 and what developers are planning is covered in Quantum computers and Bitcoin.