> For the complete documentation index, see [llms.txt](https://protocol.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://protocol.bsvblockchain.org/concepts/privacy-and-identity.md).
# 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](/specification/signature-hashing.md)). 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](/specification/opcodes.md#cryptography)).
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.
