Change Address

Alice has previously received 120,000 sat, the smallest units of bitcoin, and wants to pay 100,000 sat. In this example her funds form one UTXO: one unspent output of an earlier transaction. It becomes an input to the payment and is spent in full. With a fee of 2,000 sat, the recipient receives 100,000 sat and the remaining 18,000 sat goes to a new output in Alice’s wallet. It resembles paying with a larger banknote and getting change, but both amounts are allocated within one transaction. Alice does not have to wait for the recipient to refund anything. The wallet normally chooses the change address itself. A block explorer may therefore show two destination addresses even though Alice paid one person. Once confirmed, change is a new UTXO with its own output identifier, the outpoint; it is not an unspent fragment of the old output. An outpoint combines the transaction identifier, txid, with the position of the output within that transaction. Alice can use it in later payments like her other funds. [1]

The scriptPubKey script sets the conditions for spending an output. It does not explain why you sent the money. A block contains amounts and scriptPubKey scripts, not labels for payer, recipient or change. A wallet recognizes its own change outputs from its derivation records; a block explorer or analyst infers their purpose. Neither output order nor a rule that the second output is change is reliable. A transaction may have no change, one change output, several outputs controlled by the sender or outputs belonging to several participants. The label change therefore describes an output’s relationship to a wallet. It is not a separate property recorded by the protocol. [1]

A heuristic is an inference from indirect clues. Payjoin and CoinJoin allow several participants to construct a transaction together, so simple inferences can fail. A BIP is a technical proposal or standard document. Common heuristics identify change through clues such as an output with the same script type as the inputs, a non-round amount, a new address or an amount matching the calculated remainder. Such inferences can work for ordinary two-output payments and link later spends, but each has counterexamples. BIP78 Payjoin deliberately undermines the assumption of common input ownership and the identification of change from script type or round amounts. CoinJoin, batched payments and transfers between one’s own addresses add further ambiguity. An inference must state its uncertainty and supporting evidence; a heuristic alone is neither protocol proof nor proof of legal ownership. [4] [14]

A PSBT is a package containing a proposed transaction and supporting information that a wallet and signing device can exchange. Multisig requires approval under a rule involving several keys. BIP32 key derivation data in PSBT outputs allows a hardware or offline signing device to verify proposed change. The device must derive the output itself and check that it follows the same wallet rules. BIP174 describes checks for a single key and for Multisig; with multiple signatures, the presence of one local key in the output is not enough. A malicious coordinator assembling the transaction can replace change with its own output or hide the remainder in an excessive fee. Before signing, therefore, verify the recipient outputs, total fee and every claimed change output on a trusted display. [5]

For the calculation, let I be selected funds, R recipient payments, F the fee and C the change: C = I − R − F. RPC is a programmatic interface for issuing commands to a node. Coin Selection, the process of choosing UTXOs, determines the inputs, fee and possible change together. An exact-match set of inputs needs no change output. Otherwise, the wallet compares the remainder with the cost of creating the output and spending it later. Bitcoin Core’s fundrawtransaction RPC can add at most one change output and returns its position. Sending all selected funds to recipients deliberately creates no change. Manual selection through Coin Control changes the inputs and therefore the change amount, but every selected input is consumed in full. Review the final inputs, recipient amounts, fee and change, not just the payment amount. [9] [10] [13]

An HD Wallet can repeatedly derive many keys and addresses from one starting secret. A derivation path specifies which address to calculate; BIP identifies a technical proposal or standard document. An HD Wallet normally derives receiving addresses on an external branch and change addresses on an internal branch. BIP44 designates change=0 as the external branch and change=1 as the internal branch. For a native SegWit account, example paths are m/84'/0'/0'/0/i and m/84'/0'/0'/1/i. This is a wallet convention, not a consensus rule; a descriptor-based wallet may use different rules. A new internal address limits address reuse. Returning the remainder to the original address is valid, but links the payment history and can make it easier to associate that history with a particular person. [2] [3]

The xpub notation below represents an extended public key: it can derive descendant public data, but cannot itself sign payments. A seed is the secret starting value used to derive keys. An output descriptor describes the script type, keys, their origin information and the rule for deriving further addresses. The pair wpkh([fingerprint/84h/0h/0h]xpub…/0/*) and …/1/* can therefore describe both the receiving and change branches; BIP389 allows several branches to be expressed together. The internal flag tells the wallet which descriptor to use for change, but does not modify the resulting script itself. During recovery, the seed alone may not be enough to find all funds. Without the account information, script type and derivation method, a wallet may overlook valid change outputs even though the necessary keys still exist. [6] [7] [8]

Dust refers to a very small output assessed under a node’s transaction relay rules. The applicable limit is calculated from the output type, the estimated data size needed to spend it later and the configurable dust relay feerate. It is not one universal satoshi amount or a consensus prohibition. A wallet may also reject change above this limit if creating the output and spending it later would cost more than the amount returned. This economic threshold depends on the current fee rate, the estimated future fee rate and the script size. Omitting change increases the current fee; an excessively small output, in turn, may become prohibitively expensive to spend later. [12]

Replace-by-fee (RBF) replaces an unconfirmed transaction with another transaction paying a higher fee. Bitcoin Core’s bumpfee RPC may cover the difference by reducing change, adding inputs or creating a new change output. Change may disappear if it falls below the threshold set by node rules or economic viability. Spending unconfirmed change creates a subsequent transaction that depends on the original transaction; replacing the original can invalidate that dependency. The bumpfee command refuses a replacement if the wallet or the node’s mempool, its queue of unconfirmed transactions, already contains a transaction spending an output of the original payment. CPFP (Child Pays for Parent) creates a follow-up transaction instead of replacing the original. It spends a wallet-controlled output from the original payment and pays a higher fee, raising the combined fee rate to encourage miners to confirm both transactions together. Until replacements are settled, do not treat an unconfirmed txid or output reference, the outpoint, as final. [11] [15]

Recovery needs to find both receiving and change addresses. For a conventional single-signature wallet, the correct Seed Phrase (recovery words), any passphrase you used and compatible wallet settings usually achieve this. A seed is the secret starting value for deriving keys; a passphrase is an additional password if you chose to use one. Not every user therefore needs to record descriptors manually. With custom settings or Multisig, where several keys govern approval, the words alone may not suffice. Keep the wallet description too: network, account, script type, derivation rules and, for Multisig, every participant’s extended public key or xpub, key order and required signature count. If the /1/* branch is missing, recovery may miss change and show a lower balance. Check known addresses and outputs on both branches, the derivation range and where history scanning starts. A recovery test should also establish that you can prepare and correctly sign a payment. [2] [6] [7]