Wallet privacy
What key derivation (BRC-42) hides by default, what it does not, and the four leaks a BSV wallet still has to design against.
The blockchain is public and permanent. Anything written to it can be read by anyone, now and in forty years, and cannot be taken back. Privacy is therefore a design decision made before a transaction exists, not a setting applied afterwards.
Key derivation closes the biggest leak, a reused address, by default. Four others remain, and they are in your hands.
What you get for free
Every payment goes to a key derived for that payer and that payment (BRC-42), from a secret only the two parties share. The practical consequences:
- No address reuse. There is no static address to publish, so there is nothing for an observer to group payments around.
- No scanning for your money. The recipient never has to search the chain for outputs that might be theirs. They are told directly, as part of the payment.
- Nothing to correlate across relationships. Keys between you and one person tell an observer nothing about your keys with anyone else.
What an observer still sees
Every transaction is public: amounts, the outputs spent, and the time. What an observer cannot do by default is attach a name to any of it, or tell that two outputs belong to the same person, unless something below gives it away.
The four leaks that remain
1. Spending outputs together
Observers assume that the inputs to one transaction belong to one person. Spend an output received from your employer alongside one received from a friend, and you have told anyone looking that the same person received both.
This is the main on-chain leak left, and it is a coin selection decision. See Coin selection.
Do
Prefer selections that keep outputs from unrelated counterparties apart, even though combining them would be marginally cheaper.
2. The services a wallet talks to
A wallet asks header services for headers, broadcast services to send transactions, and overlay services about tokens. Each request tells that service something: which transactions you care about, and the IP address asking.
Do
Let users choose or self-host their services, and say in one line what each one learns. See Nodes and verification.
Don't
Query a service once per output or once per balance refresh in a way that maps the user's whole wallet to that provider. Batch, and prefer services that do not need to know which outputs are yours.
3. What apps are allowed to ask
A connected app can ask the wallet for identity information, for key linkage, for lists of outputs. The risk assessment (BRC-151) is blunt about this: money, permissions, transaction history, identity and credentials can all pass through one interface, which makes that interface a control point over much of a person's digital life.
The design answer is to ask for as little as the product needs, and to make the wallet's side of the conversation easy to read. See Connecting a wallet.
4. Key linkage revelation
This is the one most likely to be designed badly, because it sounds like a technicality and is not.
Key linkage revelation (BRC-69) lets a user reveal the mathematical link between their identity key and keys derived from it, so a third party can confirm that certain activity was theirs. There are legitimate reasons: proving a payment was yours, or satisfying an audit.
There are two kinds, and they are not close to equivalent:
| What is revealed | Scope | |
|---|---|---|
| Specific | One offset linking the identity key to one child key | That protocol, that key, that counterparty |
| Counterparty-wide | The root shared secret with one counterparty | Every key and every encrypted message with that counterparty, past and future |
Counterparty-wide revelation does not expire
A counterparty-wide revelation is not limited to the period or the purpose it was requested for. Once disclosed, the recipient can derive keys for that relationship indefinitely, and can decrypt messages that were encrypted under them. The specification requires that wallets not describe it as narrower than it is.
Do
Name what is being revealed, to whom, and for how long it keeps working. "This lets Example Audit see every payment between you and Example Shop, including future ones" is the honest version.
Don't
Offer counterparty-wide revelation where a specific one would answer the question. Never bundle either into a general permission grant at connect time.
Don't
Let an agent wallet reveal key linkage at all. See Wallet setups.
Identity is separate from payment
A payment does not carry a name. Identity is presented deliberately, as a Pass, when something actually requires it, and a Pass can prove one attribute without revealing the rest. Keeping those two things apart in your product is most of practical privacy. See Identity.
Don't
Attach a user's identity key to routine payments because it makes your activity list prettier. It permanently links their name to their spending.
Writing data on chain
BSV is used for data as well as payments, and data written on chain is public and permanent in exactly the way a payment is. See Storing data on chain for the design.
Do
Encrypt anything personal before it is written, and say plainly that what goes on chain cannot be deleted.
Don't
Write personal data on chain in the clear, even where it looks harmless. There is no delete, and context changes over decades.
What to say to users
Don't
Call payments "anonymous" or "private". Both are false.
Say what is true and what it depends on:
Payments on BSV are public, but they do not carry your name, and each one uses a new key. What can link them is spending them together, so your wallet keeps money from different people apart where it can.
Related
Written from: BRC-42, BRC-43, BRC-69, BRC-72, BRC-93, BRC-94, BRC-100, BRC-151.
Checklist
The rules on this page, in a form you can work through.
10 rules