Privacy is neither one feature nor a binary state. It emerges from the threat model, a wallet's handling of addresses and UTXOs, transaction acquisition and broadcast, the network layer, and metadata disclosed to counterparties or services.
The blockchain permanently exposes inputs, outputs, amounts, Script types, and ordering. An address contains no legal name, but once linked to an identity, the history and future movement of related UTXOs can be analyzed again. Privacy is therefore not concealment of consensus data.
An observer may be a counterparty, KYC exchange, wallet-backend operator, network peer, analytics company, or someone with device access. Each sees a different layer and may combine the on-chain graph with an IP address, account, invoice, timing, or physical presence. Measures must match the specific adversary.
A fresh receive address for each payment prevents direct reuse links but is insufficient alone. The wallet must identify change correctly and never return it to a public or reused address. A published donation address becomes a permanent surveillance point, and a later joint spend can reconnect histories that looked separate.
A multi-input transaction often supports the common-input-ownership heuristic: an observer assumes shared control of its inputs. Coin control can prevent merging UTXOs from different origins, but incorrect manual selection can reduce privacy. No-change selection, avoid partial spends, and separate labels trade fees against future linkability differently.
Round amounts, exact remainders, timing, output order, Script types, and unusual fees can identify a payment, change, or wallet implementation. No individual heuristic proves ownership, yet several weak signals can form a strong probabilistic link. RBF or later consolidation may reveal further relationships.
A remote server queried for specific addresses can learn a wallet cluster before any spend. Using a personal full node limits this leak when the wallet avoids third-party indexers. Compact block filters under BIP 157/158 reduce exposed queries, while IP metadata, timing, and broadcast method remain separate concerns.
CoinJoin combines multiple participants in one transaction and weakens simple input-to-output mapping; it creates neither invisible coins nor automatic anonymity. PayJoin under BIP 78 adds a receiver input to an ordinary payment and breaks the common-input heuristic. Results depend on implementation, participant set, later spending, coordinator, and network metadata.
Silent Payments under BIP 352 allow publication of a reusable payment identity while each sender derives a unique Taproot output. The receiver must scan the blockchain with a scan key and back up the required keys and labels. This trades less public linkage for greater wallet complexity and support requirements.
A shared xpub can derive and monitor much of a wallet's history without spending authority; disclosure is a long-lived privacy incident. A KYC service can connect a withdrawal to an identity and future graph. Merchants, block explorers, cloud backups, push notifications, and analytics can add metadata absent from the blockchain.
Before paying, define the adversary, UTXO origin, intended separation, and information available to the receiver. Verify the receive address on-device, change, selected inputs, fee, broadcast path, and whether the wallet uses your own node. Inspect the confirmed transaction, but never promise zero traceability: privacy is continuous and disclosed links cannot be revoked. Sources: Bitcoin.org — Protect Your Privacy; BIP 78 — A Simple Payjoin Proposal; BIP 157 — Client Side Block Filtering; BIP 352 — Silent Payments; Bitcoin Core 0.21 — Avoid Partial Spends.
For the clearest picture, read this entry together with Pseudonymity, CoinJoin, Coin Control, KYC, Bitcoin, Bitcoin address. The reverse links also lead from Watch-only Wallet, Coin Control, Change output, Extended Public Key (xpub).