Coin control: choosing which outputs to spend

The workflow is straightforward once the outputs are visible. The wallet lists each unspent output with its value, its address and the transaction that created it. The user labels the ones that came from a particular source, locks the ones that should never be spent casually, and then, when making a payment, selects the inputs explicitly. The wallet still computes the fee and builds the transaction; it simply does not choose the inputs.

Two details matter. The first is change. A controlled spend almost always produces change, and if that change is returned to the wallet's normal pool it will later be selected automatically and merged with everything else. Bitcoin Core's coin control therefore allows a custom change address, which lets the user send the change back to the same isolated group. Without that step, the isolation lasts exactly one transaction.

The second is labelling. Coin control is only usable if the user knows where each output came from, and that knowledge has to be recorded when the output arrives. A wallet that shows a list of anonymous outputs is technically capable of coin control and practically useless for it. This is why the feature is paired with address labels and with the listunspent and listaddressgroupings RPCs, which expose the wallet's own view of which outputs belong together.

The first cost is fees. Automatic selection is good at finding a combination of inputs that covers a payment with little waste. A user who insists on a particular set of inputs may end up with a larger transaction, more change, or both. Bitcoin Core's own documentation of the related avoidpartialspends behaviour is explicit that the privacy improvement can raise fees because the selection is constrained. Coin control is that trade-off made manual and deliberate.

The second cost is complexity, and it is the one that stops most people. Coin control requires the user to understand the UTXO model, to label outputs as they arrive, and to remember which group is which months later. It is a discipline rather than a setting. A user who applies it once and then forgets will have spent the fee and gained nothing, because the next automatic spend will merge the groups anyway.

The third cost is the risk of error. Selecting inputs by hand can produce a transaction that spends an output the user meant to keep untouched, and there is no undo. The mitigation is the lock: an output that is locked cannot be selected by accident, and unlocking it is a deliberate act. The consolidation page covers the case where merging is the intended outcome, and the dust page covers the outputs that should never be selected at all.