When you tap "Send" in your wallet app, more happens behind the scenes than you might expect. Your wallet has to decide which of your "bills" it uses for this payment, has to weigh fees against privacy, and (if multiple devices or people need to sign together) has to find a secure way to coordinate that without a private key ever leaving its own device. This post shows how that's actually solved in the code.
Wallet and Node: Two Separate, Interchangeable Building Blocks
A misconception that sticks around: "my Bitcoin wallet" and "my Bitcoin node" sound like the same thing, but technically they don't have to be. Bitcoin Core can run entirely without wallet functionality enabled, as a pure node that only checks rules and relays data (relevant, for example, to the RPC usage by third-party applications described in Part 7 of this series). Conversely, wallet software can also work entirely independently of a self-run node and instead rely on someone else's trusted node (which does come with certain trust and privacy trade-offs, since you then reveal to that other node which addresses you're interested in). Most users never notice this separation, because popular wallet apps conveniently bundle both roles into a single application, but under the hood these are two independent, interchangeable software components.
Why Bitcoin Doesn't Have "Balances" in the Classic Sense
Unlike a bank account, which simply stores a single number, Bitcoin technically has no "balance" as such. Instead, you own a collection of individual, unspent outputs from earlier transactions, similar to a wallet full of individual bills of different denominations. The balance shown in your app is simply the sum of all these individual "bills" (technical term: UTXOs, "Unspent Transaction Outputs"). To make a payment, your wallet therefore has to decide: which of these individual "bills" do I use to add up to exactly this amount?
Three Strategies for the Same Decision
Bitcoin Core uses several different strategies for this decision (src/wallet/coinselection.cpp), applied depending on the situation:
Branch and Bound is the preferred strategy and pursues a clear goal: finding a combination of existing UTXOs that hits the target amount as exactly as possible, without needing an extra "change" output. That sounds like a minor detail, but it's doubly beneficial: a transaction without a change output is smaller and therefore cheaper in fees, and it leaves fewer visible traces that would let outsiders link your various UTXOs to each other. The algorithm evaluates possible combinations via a so-called "waste" metric, which factors in, among other things, whether the current network fee is currently higher or lower than what can be expected long-term, and tries up to 100,000 different combinations before giving up.
Single Random Draw is the simpler fallback: if Branch and Bound can't find a suitable exact combination, this method simply picks UTXOs in random order until the target amount is reached, faster, but practically always comes with a change output.
The Knapsack solver is the oldest of the three approaches, historically introduced before Branch and Bound, and solves a variant of the well-known computer-science "knapsack problem" (how do I pack a bag of limited volume as optimally as possible?), applied to UTXO selection.
In practice, your wallet tries several of these strategies in parallel and ultimately picks the combination with the best score.
Descriptor Wallets: Addresses From a Formula Instead of a List
Bitcoin wallets used to store every single address separately, with all the downsides that brings for backup and recovery. Modern wallets instead use so-called output descriptors: compact, standardized text formulas that precisely describe how an entire series of valid addresses is derived from one or more keys (e.g. "SegWit single-signature address, derived from this one master key, numbered sequentially"). The big advantage: a single descriptor can represent thousands of future addresses, your entire backup shrinks down to this one short formula plus your secret key, instead of an ever-growing list of individual addresses.
PSBT: How Multiple Devices Jointly Sign a Payment Without Having to Trust Each Other
With hardware wallets or multisig accounts (where, say, two of three signers need to agree), a technical problem arises: how do multiple devices or people exchange a transaction until enough signatures are collected, without a private key ever needing to unnecessarily leave its secure device?
The solution is called PSBT ("Partially Signed Bitcoin Transaction," officially BIP174) and is a standardized, interchangeable file format (recognizable by its characteristic first five bytes in the file header, PSBT_MAGIC_BYTES in src/psbt.h). A PSBT file gradually collects all the necessary information (which UTXOs are being spent, which public keys are involved, which partial signatures already exist) and gets passed back and forth between the participating devices until it eventually becomes a fully signed, ready-to-broadcast transaction. This exact mechanism is, today, practically what sits behind every hardware-wallet-plus-software-wallet combination you may have used yourself.
A Worked Example: Why UTXO Selection Costs Real Money
To understand why all this effort pays off, a simple worked example helps. Suppose you want to pay 0.05 BTC, and your wallet balance consists of three individual UTXOs: 0.03 BTC, 0.02 BTC, and 0.1 BTC. Branch and Bound would immediately spot the combination of the first two (0.03 + 0.02 = exactly 0.05 BTC), no change needed, a lean transaction with just two inputs. A less clever selection might instead simply grab the large 0.1 BTC UTXO, but would then have to additionally send 0.05 BTC in change back to a new address of your own, a transaction with an extra output that's noticeably more bytes in size and therefore, at the same fee rate, genuinely more expensive in real satoshis. For a single payment, the difference might seem small, but for a wallet processing thousands of transactions over time (say, at a payment provider), thoughtful coin selection adds up to real cost savings.
The Trade-Off Between Privacy and Fees
Interestingly, coin-selection decisions sometimes pull in opposite directions when you want to both save on fees and reveal as little about yourself as possible. The "cheapest" option is almost always to use as few, as large UTXOs as possible, that keeps the transaction small. From a privacy standpoint, though, it can be smarter to deliberately avoid combining several smaller, unrelated UTXOs, since using them together in a single transaction would tell an outside observer they belong to the same person (chain-analysis firms call this the "common-input-ownership heuristic"). A well-designed wallet therefore constantly has to balance "as cheap as possible" against "as discreet as possible"; the waste metric described above is ultimately an attempt to translate this trade-off into a single, comparable number.
Why Private Keys Should Never Leave Your Own Machine
A fundamental security principle runs through the entire wallet architecture, even though it's only been implicit so far: at no point does your wallet software need to send your private key anywhere else, neither to the Bitcoin node itself (Part 7 of this series shows that a node can theoretically be run entirely separately from any wallet) nor to a third-party server. Signing happens locally, on the device that holds the key, on a hardware wallet, that means inside the small, specially secured USB device itself, not on the connected computer. That's exactly why the PSBT format described in the previous section matters so much: it transports everything needed to sign WITHOUT the key itself ever having to travel along, only the finished signature makes its way back.
A Warning From History: When Security Becomes Its Own Risk
As important as protecting private keys is, Bitcoin's history also knows the opposite extreme. In 2011, a once-well-known Bitcoin project irretrievably lost around 7,000 bitcoin, not through a hack or theft, but because the deliberately very complex, self-built encryption solution for its own backups ultimately simply couldn't be decrypted anymore. The lesson from this, which still runs through serious security recommendations today: every additional security measure has to be weighed against the risk of eventually locking yourself out. A wallet setup so complicated that you (or your heirs, years later) can't use it correctly under stress isn't security gained, it's just a different risk traded in, one reason why most established recommendations deliberately favor simple, well-documented, widely tested standard solutions over homemade special constructions.
What You Can Take Away for Choosing Your Own Wallet
In practical terms, this means: not every wallet app is equally good at coin selection, and it's worth a closer look before choosing a wallet for larger amounts or frequent use. If a wallet supports PSBT, you can easily combine it with a hardware wallet without having to switch providers later if you want more security. If a wallet transparently shows you which UTXOs it uses for a payment (some advanced wallets even allow manual UTXO selection), you can take deliberate control of the fee-versus-privacy trade-off described in this post yourself, instead of leaving it entirely to the software.
Conclusion: A Wallet Is More Than a Pretty Interface
Coin selection, descriptors, and PSBT run almost invisibly in the background, but these three building blocks are exactly what determines whether a payment is cheap or expensive, private or easily traceable, and whether a multisig setup is practically usable or an IT nightmare.
Next up, Part 7: The Wire to the Outside, how external programs and apps talk to a Bitcoin node.
