Privacy and Identity

How the protocol treats keys, identity, and privacy

A Bitcoin transaction is published on the ledger in cleartext: every field is globally readable. A transaction references public keys and scripts, not the identities of the parties. Any binding between a key and a real-world identity is maintained off-chain; it is never part of a transaction. Publishing transactions in the clear is what lets any node detect double-spends against the public record; keeping identity off-chain is what provides privacy.

Keys are not identities

In the UTXO model an output is locked to a condition — commonly a public key or its hash — and is spent by supplying an unlocking script that satisfies it (typically a signature from the corresponding private key). The ledger records which key can unlock an output, not who holds that key. Two consequences follow:

• Possession of a key is not ownership. The protocol enforces that a valid signature is required to spend an output; it does not, and cannot, establish who is legally entitled to it. Ownership is established off-chain by whatever means the applicable law recognises.
• Identity is off-chain. A party may publicly associate itself with a key, but that association lives outside the blockchain (as a merchant's KYC records do). Absent such a declaration, a transaction reveals only keys.

Pseudonymous, not anonymous

The white paper describes keeping public keys private from parties not involved in a transaction — pseudonymity, not anonymity. Because every transaction carries a public key and (for spends) a digital signature, spends are attributable to a key, and a key can be linked to an identity off-chain by those who need to (counterparties, or regulated record-keepers). The protocol requires a digital signature to authorise spending value; a signature presupposes a key, and a key can be associated with an identity. This is what separates a pseudonymous public ledger from systems engineered to make spends unattributable.

Digital signatures

A spend is authorised by a digital signature over the transaction's signature-hash (see Signature Hashing). The signature is produced with the private key corresponding to the public key the output was locked to, and is verified on-chain by OP_CHECKSIG / OP_CHECKMULTISIG (Opcodes).

What the protocol verifies is narrow and exact: that the signature is valid for the given public key over the computed digest. It does not verify who controls the key. Associating a signing key with a specific person or entity — the step that turns a cryptographic signature into a legally meaningful one — is done off-chain.

What privacy a public ledger provides

A transaction contains the public keys of the parties but no information that identifies them, so privacy depends on keeping key–identity associations off-chain. If a key is publicly tied to an identity, the transactions using that key are no longer private with respect to that identity. Two protocol properties bear on this:

• Key reuse. Reusing a key across transactions links them; using a fresh key-pair per output avoids that linkage.
• Value granularity. A single large-value output can, combined with external information, reveal more than intended; splitting value across outputs reduces what any one output discloses.

How much of this to apply is an application-design decision, out of scope for the protocol itself, which only guarantees that transactions reference keys rather than identities.