Private keys, public keys, and addresses

Three items on a workbench

Imagine a workbench with three labeled drawers. The first holds secret signing material. The second holds information others can use to check signatures. The third holds a destination you can share to receive a payment.

In a simple key-based Bitcoin payment, a private key is secret material used to authorize spending. A related public key helps verify that authorization. An address is an encoded description used by wallet software to construct a destination’s spending conditions. It is not a balance container.

Sharing an address for payment does not share the private key. Sharing the private key is radically different: another party with the necessary signing material may be able to authorize spends. The important boundary is capability, not whether a string looks complicated.

The address is not always “the public key hashed”

That phrase is a useful description of some older address types, but a poor universal rule. Bitcoin has multiple output types and address encodings. Some commit to a public-key hash, some to a script, and Taproot destinations use a witness program involving a tweaked public key.

A wallet interprets the address format and network before constructing an output. An address checksum can help catch transcription mistakes; it does not establish that the destination belongs to the person you intended to pay. A validly encoded address can still be the wrong destination.

For a reader, the practical mental model is: an address tells the sender’s software how to form a payment destination; spending later requires satisfying that destination’s conditions.

Follow a fictional payment without generating keys

Tariq asks Lina for a destination. Lina’s wallet supplies an address. Tariq’s wallet decodes it and creates an output. Later, Lina’s signing device helps construct the evidence required to spend that output.

The spending conditions are the link between these moments. Tariq does not need Lina’s private key, and Lina does not need to receive a secret object from Tariq’s wallet. The public record identifies an output with conditions; Lina retains the capability needed to satisfy them.

A watch-only wallet makes the separation visible. It can recognize relevant outputs and show activity without possessing the private keys necessary to sign. Conversely, possessing a key without the right wallet metadata can make discovery and recovery harder even when the cryptographic capability exists.

Do not apply the diagram mechanically to every chain. Address derivation, signature schemes, account models, and smart-contract control differ. Even within Bitcoin, multisignature and script conditions make “one address, one private key” an unreliable generalization.

Label the permissions

For each item in this fictional inventory, write what it lets a program do:

• A receiving address printed on an invoice.
• Public information imported into a watch-only wallet.
• A signing key kept on an offline device.

Expected result: form a destination; monitor relevant activity under the imported descriptor or key information; produce relevant signing evidence. None of these labels implies the person using the item has been identified in the real world.

A useful developer inspection exercise is to look at a decoded output’s scriptPubKey and compare it with the wallet’s displayed address type, using a local test environment. Do not paste a real recovery phrase or private key into an explorer, this publication, or a chat to complete the exercise.