Glossary / Addresses & keys
Public key
- Definition
- A public key is the point on the secp256k1 curve derived from your private key, publishable without risk, and the value a signature is checked against when you spend.
Multiplying the private key by a fixed point on the curve produces the public key, and no known method reverses that step. Compressed keys occupy 33 bytes, and Taproot trimmed them further to the 32-byte x-only form defined in BIP-340. You rarely see one as a user, because most addresses publish only a hash of the key and reveal the key itself when the coins finally move.
How it works
Public keys come out of one specific curve, and its arithmetic does all the work. Bitcoin uses secp256k1, defined by the equation y squared equals x cubed plus 7 over a large prime field, together with an agreed starting point called the generator. Adding that generator to itself as many times as the private key says produces another point on the curve, and that point is the public key. The operation is fast in one direction and, with every technique known today, infeasible in the other, which is the whole basis of bitcoin ownership.
Three encodings appear in practice. The original uncompressed form spends 65 bytes writing out both coordinates behind a 0x04 prefix. The compressed form keeps only the x coordinate and a parity byte, 33 bytes in total, and has been the default for well over a decade. Taproot goes one step further with x-only keys of exactly 32 bytes, dropping the parity byte because BIP-340 fixes the convention instead.
Where the key appears on chain depends on the output type. A legacy or SegWit version 0 output commits to a 20-byte hash of the public key, so the chain shows the hash and nothing else until the coins are spent, at which point the spender must reveal the key that hashes to it. A Taproot output is different: the 32-byte output key sits in the address itself, visible from the moment funds arrive.
Why this matters when you buy bitcoin
Two practical situations put a public key in front of an ordinary buyer, and both are easy to get wrong.
The first is proving that an address is yours. Under the EU transfer of funds regulation, an exchange must verify that a self-hosted address really belongs to its customer before sending more than 1,000 euros to it, and comparable checks apply in several other jurisdictions covered in our country guides. The standard proof is a signed message: your wallet signs a challenge with the key behind the address, and the exchange verifies it against the public key. Nothing secret leaves your device, so this request is safe to comply with, unlike a request for the key itself.
The second is the extended public key, the xpub your wallet can export. An xpub is not a spending credential, and handing one over cannot cost you coins directly. It does hand over your financial history: anyone holding it can generate every address that wallet will ever use, past and future, and read the balance and every transaction attached to them. Portfolio trackers, tax tools, and accountants ask for xpubs routinely. Give one out only where you would be comfortable handing over a lifetime bank statement, and use a separate account or wallet where you would not.
Following a key onto the blockchain
Take a wallet using the standard native SegWit path, m/84'/0'/0'/0/0. The key at that path is 33 compressed bytes. The wallet hashes it, first with SHA-256 and then with RIPEMD-160, producing 20 bytes, and encodes those bytes as a bc1q address. Everything sent to that address is now locked to a hash, and the network has never seen the key.
When you spend, the witness field carries two items: a signature and the 33-byte public key. Every node hashes the key, checks that the result matches the 20 bytes the output demanded, then verifies the signature against the key. Only if both hold does the spend stand. From that block onward the key is public, which is a good reason not to leave a balance sitting at an address you have already spent from.
Public key vs private key
The private key is chosen at random and the public key is computed from it, never the other way round. That asymmetry decides how each one is handled: publishing a public key is routine and costs you nothing, while publishing a private key hands over the coins immediately and irreversibly. Backups protect the private side, since the public key can always be recomputed from it in microseconds. Verification uses the public side, which is why strangers and nodes can check your signature without ever being trusted with anything.