Skip to main content

Bitcoin coin control privacy checklist

Which coins to spend together, when to avoid change and how payment plans are ranked: the checklist the am-i.exposed coin selector follows for every payment.

Spending checklist

A decision tree for each payment. The labeling rules come first (never merge KYC with no-KYC, CoinJoin outputs with other coins, or identifiable change with other coins), then these rules in order. Each plan in the coin selection advisor shows its decision path, and alerts above the plans cover rules 3, 6 and 7.

  1. Paying someone who already knows one of your coins (they sent it to you, or you paid them before)? Spend that coin: they learn nothing new about your activity.
  2. Otherwise spend one coin that covers the payment and is close to the amount (change of at most 10% of the payment). If the change would be under 5,000 sats, give it to the miners and leave no change.
  3. Handle change one coin at a time: pay with no change, or send leftover change to a Lightning swap. Until then, keep it frozen.
  4. Torn between merging coins and one coin that leaves a lot of change? Prefer the option that uses up the change or leaves a small one (at most the payment), and accept what the merge implies, unless it breaks a rule above (change, KYC, CoinJoin) or joins 3 or more unrelated groups of coins against a coin with moderate change.
  5. If a payment needs several coins, merge coins from the same observer or platform. Otherwise accept the merge, knowing each observer learns more about your activity. Never merge change an observer can tell is change, and never spend two outputs of the same transaction together: it shows that payment was to yourself.
  6. Never send to an address that was used before. Ask for a new one.
  7. Watch for round amounts and for a recipient address of a different type than yours: both reveal which output is your change. Paying on-chain via a swap from Lightning avoids both.
  8. Paying a round amount? Raise the fee a little so the change is round too: the round-amount rule then cannot tell payment from change.
  9. When a merge cannot be avoided, merging only CoinJoin outputs is the least bad: they carry no history. It still links them and shrinks their anonymity, so it is never good.

How plans are ranked (Privacy first)

The advisor compares what each plan lets an observer learn, step by step: a plan goes first when it is better at the first step where two plans differ.

  1. Hard rules: fewer violations of never merging KYC with no-KYC coins, CoinJoin outputs with other coins, change an observer can tell is change with other coins, two outputs of one transaction, or toxic coins.
  2. The recipient: a plan spending only coins the recipient already knows goes first.
  3. Change: none, then small (at most the payment), then big (more than the payment), then huge (10x the payment or more), then toxic (under 10,000 sats, or from a CoinJoin coin, whatever its size). A merge that uses up the change goes before one coin with more change (rule 4), but a merge joining 3 or more unrelated groups of coins counts as big change here.
  4. New links: fewer groups of coins joined that nothing linked before. At equal links, links one label observer already knows, or between CoinJoin outputs only, go first.
  5. Change that the round-amount or address-type rule would point at: fewer such rules first.
  6. Probable links confirmed: fewer first.
  7. Inputs: fewer first.
  8. Fee, including leftover paid to miners: lower first. A difference below 1,000 sats or 1% of the payment, whichever is larger, counts as none.