Coin Selection

Anna wants to pay 60000 sat. Her wallet prepares the payment: it is an app or device that lets her receive and send bitcoin. The abbreviation sat means satoshi, the smallest unit used to record amounts in Bitcoin transactions. She has a UTXO worth 100000 sat. Much like a banknote, she cannot simply deduct part of it: an input of the new transaction spends that entire output. The transaction creates an output of 60000 sat for the merchant and, with a fee of 1000 sat, another 39000 sat for Anna. This second output is called change. It is not a later refund from the merchant; it is created within her own transaction. The fee is the difference between the sum of the inputs and all the outputs. [1] [7]

The wallet can fund the same payment with different UTXOs. More inputs usually mean more data, and therefore a higher fee at the same fee rate. The fee is not a percentage of the amount sent. It depends on the virtual size of the transaction, measured in vB, or virtual bytes, which account for the different weight of its components. Consider a UTXO of 10000 sat whose input is estimated to add 68 vB. At 10 sat/vB, that input costs 680 sat, leaving 9320 sat to contribute to the rest of the payment. This is its effective value. Other parts of the transaction still have costs; the actual input size depends on the spending conditions recorded in its script and on the signature data. A script is a short program describing the conditions for spending. In a typical payment, the wallet uses a private key, a secret numerical value, to create a digital signature: a verifiable authorization to spend. [2] [3] [7]

Anna may have received many small amounts over time. Combining them into a larger output of her own is called consolidation. She may need fewer inputs later, but consolidation costs a fee now and publicly links the outputs used. Automatically combining everything is therefore not a sensible default. Bitcoin Core also compares costs using a waste metric: a score accounting for the difference between input costs now and at an assumed long-term fee rate, plus the cost of creating and later spending change, or the excess given to the fee. The long-term rate is a working assumption, not a forecast. This score measures cost, not privacy. [2] [6]

Anna has labelled one incoming payment as salary and another as a gift. Spending them together gives a blockchain observer a clue that they are related. It is not proof that all inputs belong to one person: transactions can also be built collaboratively. Coin Control lets her choose particular UTXOs, while labels help her remember their origin. A label is a note in the wallet, not a message written to the blockchain. BIP 329 describes how to transfer these notes, along with information about whether the wallet treats a particular output as spendable. This is a local wallet setting; it does not change the rules of the Bitcoin network. The format does not select funds itself. Exported labels can reveal sensitive connections, and even a payment without change does not guarantee anonymity. [4] [6]

Not every part of the displayed balance is immediately usable. The wallet may deliberately exclude some outputs; others await confirmation or satisfaction of spending conditions. Selection must also respect transaction size and weight limits. Spending an unconfirmed receipt makes the new payment depend on the earlier transaction that created it, called an ancestor in this context. Confirming the whole chain may require an additional fee. RPC, the interface through which programs control Bitcoin Core 29.0, provides an include_unsafe option in walletcreatefundedpsbt. It allows risky unconfirmed inputs to be included. If the original transaction is replaced in a way that removes the required output, the dependent payment cannot confirm. Simply removing the original transaction temporarily from a node’s memory does not, by itself, change its validity. [3] [5]

How does the wallet search its options? Branch-and-bound, or BnB, tries combinations of inputs and abandons search branches that cannot produce a suitable result. It aims to fund a payment without a separate change output. An exact match is not required: the allowed range includes an excess up to the cost of creating and later spending change. That excess becomes a fee; it does not remain hidden somewhere in the wallet. A payment without change is therefore not necessarily the cheapest possible payment. The search has a limited number of attempts and may miss an existing solution or the best of all possible combinations. [2]

Bitcoin Core 29.0 compares candidates from BnB, Knapsack and Single Random Draw (SRD). These are different methods of finding a suitable set of inputs. It adds CoinGrinder when the effective fee rate exceeds three times the long-term rate; that method seeks a low-weight selection with change. It compares the resulting candidates using the waste metric explained above. If the user chooses to subtract the fee from the recipients’ amounts, BnB is skipped. This describes that particular version, rather than a procedure every wallet must follow or a claim about the latest release. [3]

You do not need programming parameters for an ordinary payment. Before signing, however, you do need to understand the recipient, amount, total fee and your own change. For advanced users, walletcreatefundedpsbt in Bitcoin Core 29.0 lets you identify inputs with txid, the original transaction identifier, and vout, the index of its output. add_inputs controls whether the wallet may add further inputs. Watch the different units: fee_rate uses sat/vB, whereas feeRate uses BTC/kvB, meaning bitcoin per 1000 virtual bytes. The result is a PSBT, a format for passing a prepared transaction around for signing. Creating a PSBT alone neither sends anything nor confirms a payment. Neither manual selection nor this format guarantees the correct recipient or the validity of unconfirmed inputs. [5]