Pseudonymity

The Bitcoin whitepaper separates public keys from public identity while noting that the transaction flow remains visible. A pseudonym hides a name only until another datum creates a link. Once linked, earlier and later activity can be reanalyzed; anonymity is not acquired once and forever.

An address is a payment instruction derived from a key or script, not a username or reliable proof of one person. One user can control many addresses, and one spending condition can involve several people or devices. A signature proves authorization under Script, not the signer's legal identity.

Each on-chain transfer spends earlier UTXO and creates new outputs. Amounts, Script types and ancestry are public, letting observers build a probabilistic graph of pseudonyms. The graph normally lacks names, but an exchange record, invoice or published address can label part of it.

Address reuse turns a one-time payment instruction into a persistent public identifier. Counterparties can then see shared history and monitor later receipts or spends. A fresh receive address for every payment limits this direct link but does not prevent other heuristics from reconnecting activity.

A wallet commonly returns excess value as change. Change detection and the common-input-ownership heuristic can join inputs into a wallet cluster, although neither is cryptographic proof of common ownership. CoinJoin, PayJoin, coin control and later spending can weaken or strengthen those inferences.

A KYC exchange knows an account and usually a withdrawal address; a merchant knows an order, time and amount; an in-person payment may reveal physical presence. Identity attachment occurs outside consensus but can be added to the public graph. Rotating addresses cannot revoke a previously disclosed link.

BIP 32 derives many keys from one deterministic tree. Leaking an xpub normally does not grant spending power, but it can expose extensive past and future history for that wallet branch. An xpub is therefore a strong long-lived pseudonym and should be shared only with that consequence understood.

IP address, broadcast timing, wallet backend, block explorer, cookies, push notifications, cloud backup and analytics SDKs can link an on-chain pseudonym to a device or account. A personal full node limits some third-party queries but does not automatically remove every network or endpoint leak.

Lightning adds identifiers: a public node ID and channels may be persistently recognizable, while an invoice, offer, route hint or payment hash creates other links. Off-chain payments are not normally written to the blockchain, but sender, receiver, routing nodes and service providers see different metadata.

For an audit, separate ‘the address contains no name’ from ‘nobody knows the owner.’ Check address reuse, UTXO origin, change, common inputs, published addresses, xpub, KYC counterparties, network backend and Lightning identifiers. Report linkability against a named observer, not absolute anonymity. Sources: Bitcoin whitepaper — Privacy; Bitcoin.org — Protect Your Privacy; BIP 32 — Hierarchical Deterministic Wallets; Bitcoin Developer Guide — Transactions; Lightning BOLT #7 — Routing Gossip.