> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/bitcoin-protocol-documentation/concepts/privacy-and-identity.md).
# Privacy and Identity
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](/bitcoin-protocol-documentation/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](/bitcoin-protocol-documentation/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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://hub.bsvblockchain.org/bitcoin-protocol-documentation/concepts/privacy-and-identity.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.