Coin selection
Which outputs a wallet spends, what that choice reveals, and why users should almost never see it.
A wallet's balance is not one number in an account. It is a set of separate unspent outputs, each a fixed amount received at some point. To pay someone, a wallet picks some of those outputs, spends them completely, and sends the remainder back to itself as change.
Coin selection is the choice of which ones to pick. On BSV an extra input costs almost nothing, so the choice is driven by privacy and by not breaking things, and most of the interface for it disappears.
What changes on BSV
Fees do not drive the choice. An extra input costs a tiny fraction of a penny. A wallet can spend ten small outputs in one payment, and the user will not notice the difference in what they pay.
Dust is not a category. With BSV fees, even a one-satoshi output costs less to spend than it is worth. Wallets should not label outputs as dust, hide them, or offer to "clean up" a balance.
Privacy still matters, and it is a different kind. Because the wallet derives a fresh key per payment, outputs are not grouped by a reused address. What still links them is being spent together in one transaction: observers assume that every input to a transaction belongs to the same person, and they are usually right. That is the leak worth designing against. See Wallet privacy.
Records are the real constraint. A wallet can only spend an output it knows about and holds the derivation details for. On BSV those details live in the wallet's records, not on the chain, so a wallet missing its records has a smaller spendable balance than its key would suggest. See Backups.
Baskets
A connected wallet groups outputs into named baskets, so an app's outputs, a token's outputs and ordinary spending money stay separate. Selection happens within the relevant basket, and an app that was granted one basket cannot reach into another. So keeping money for different purposes apart happens automatically, without a screen for it.
What a wallet should optimise for
In roughly this order:
- Don't break things. Never select an output another part of the wallet has reserved, such as one backing a token or a pending payment.
- Keep inputs unlinked. Avoid combining outputs received from unrelated counterparties. Combining them tells an observer that one person controls both.
- Avoid a growing tail of tiny outputs. They are still spendable, but a thousand of them make every transaction and every backup larger.
- Keep change sensible. Prefer a selection that leaves a useful change amount rather than a fragment.
Do
Select within a basket, and treat an output reserved by an app or a token as unavailable rather than as a cheap input.
Don't
Merge outputs from unrelated counterparties just because it makes a neater transaction. The saving is less than 1p, and the cost is linking two relationships that were separate.
What users should see
Almost none of this.
Do
Show one spendable balance, and show separately anything that is not spendable because it is reserved, in a token, or in another basket. "2,400 sats, plus 1 token" is honest; a single number that silently excludes things is not.
Don't
Build a manual coin-choice screen into a consumer wallet. Choosing well automatically protects privacy better than asking the user to.
Don't
Use the words "dust", "UTXO" or "coin selection" anywhere a normal user can see them.
Where manual selection still belongs
Businesses and advanced users sometimes need to spend a specific output: to prove a particular payment was theirs, to keep two income streams apart for accounting, or to move one asset without touching another.
If you offer it, put it behind an advanced view, label outputs by where they came from rather than by their transaction id, and say what selecting them will reveal.
Change
Change goes back to a key the wallet derives for itself, not to a reused address. Users do not need to see it, and nobody should ask them about it.
Recommendation
Never show change in activity. Paying 500 sats from a 2,000-sat output is one payment of 500 sats, not a payment of 2,000 sats and a receipt of 1,500.
Related
- Transactions: what an output is and how spending works
- Wallet privacy: what spending together reveals
- Backups: why records decide what is spendable
Written from: BRC-42, BRC-62, ts-stack wallet-toolbox docs.
Checklist
The rules on this page, in a form you can work through.
6 rules