Change address

Bitcoin has no concept of partial spending. If you hold one 0.05 BTC coin and pay 0.012 BTC, the transaction destroys that coin and creates two new ones: the payment, and roughly 0.038 BTC of change locked to an address only you control. On a block explorer the second output looks like a stranger being paid, and it is not.

How it works

Every bitcoin payment starts by picking whole coins to feed into it. A coin, properly an unspent transaction output, cannot be split in place: the transaction consumes it entirely and writes fresh outputs. Your wallet totals what it selected, subtracts what you are paying and what the miner will take, and sends the remainder to a destination it generated for itself. That destination is the change address.

Modern wallets keep those destinations on a separate branch of their key tree. BIP-44 fixed the layout as m / purpose' / coin_type' / account' / change / address_index, where the second to last level is 0 for addresses you hand out and 1 for addresses the wallet keeps to itself. A native SegWit wallet's first change address is therefore m/84'/0'/0'/1/0, derived from the same seed phrase as everything else, so nothing extra needs backing up.

That was not always true, and the history explains why the branch exists at all. Early Bitcoin clients drew change from a pool of pre-generated random keys, 100 of them by default. Spend past the end of the pool and a wallet.dat backup taken earlier no longer held the key sitting on your change, which is how people restored a backup and found money missing. Bitcoin Core has created only hierarchical deterministic wallets since version 0.16.0, and the look-ahead pool now defaults to 1,000 keys.

The change amount is arithmetic: inputs minus payments minus fee. Nothing in the transaction marks an output as change. A node sees two outputs and treats them identically, which is precisely why change is a privacy problem rather than a bookkeeping one.

Why this matters when you buy bitcoin

Your first change output usually appears the first time you spend coins withdrawn from an exchange, and it inherits everything that withdrawal knows about you.

An exchange that verified your passport recorded the address it paid. When you later spend from that address, the change is created by the same transaction, so anyone following the original output follows the change as well, including whichever analytics vendor the exchange pays. Splitting a withdrawal across two wallets buys nothing if you then spend from both in one transaction. Keeping exchange coins in their own wallet and paying from it deliberately is what limits how far the identity spreads.

Hardware wallets defend a second and sharper risk. A compromised computer can build a transaction whose change output goes to an attacker instead of to you, with a total that still looks correct, so nothing on the screen seems wrong. A Trezor or Ledger device checks that every change output derives from the seed it holds and flags any output that does not. The check only works if you confirm amounts on the device's own display rather than in the browser.

There is also a cost you can influence. Two outputs cost more than one: a native SegWit change output adds 31 bytes to the transaction, about 465 satoshis at 15 sat/vB, and it creates a coin that will cost roughly 68 virtual bytes to spend later. Wallets running a branch and bound coin selection try to find inputs that match the payment closely enough to skip change altogether, and that succeeds more often when your coins are varied in size than when they are all round withdrawals.

Change is also not a disposal. Paying yourself the remainder of your own coin is not a sale, but portfolio trackers routinely import change outputs as incoming purchases or outgoing sales, which corrupts a cost basis. If your tracker shows a transaction you do not recognize on the day you paid an invoice, this is normally the cause.

Tracing the change through a 0.05 BTC withdrawal

Follow one coin from an exchange to a merchant and every figure is visible on chain. You withdraw 0.05 BTC to a bech32 address in your own wallet, and it arrives as a single output worth 5,000,000 satoshis.

Weeks later you owe a merchant 1,200,000 satoshis. Your wallet holds exactly one coin, so it has to spend all 5,000,000. The transaction has one input and two outputs, roughly 141 virtual bytes, and at 15 sat/vB the fee is 2,115 satoshis. The merchant receives 1,200,000. The change output receives 5,000,000 minus 1,200,000 minus 2,115, which is 3,797,885 satoshis, and it lands at m/84'/0'/0'/1/0.

Nothing in that transaction announces which output is which. Two heuristics usually give it away: the change is the output with the unrounded amount, and the change is often the output whose script type matches the input. Wallets that round the change, or copy the recipient's script type, exist to break exactly those guesses.

Change address vs unique address

A change address and a fresh receiving address are both used once, and the difference is who is meant to see them. A receiving address comes off the external branch at chain index 0 and exists to be copied into somebody else's wallet. A change address comes off the internal branch at chain index 1 and is never shown to a payer; most interfaces will not display one unless you open a coin control screen. Both rotate for the same privacy reason, and both restore from the same twelve or twenty-four words.

Change address vs dust

Change is whatever is left over; dust is a leftover too small to be worth creating. Bitcoin Core refuses to relay an output priced below 3 satoshis per virtual byte of its eventual spend, which works out to 546 satoshis for a legacy output and 294 for native SegWit. When a wallet calculates change beneath that line it does not create the output at all and the value goes to the miner as extra fee instead. That is why paying an amount just under your whole balance can cost far more than the fee you were quoted.