Change output

Bitcoin spends whole UTXOs; it cannot debit only part of an input. A wallet choosing 120,000 sat of inputs for a 100,000 sat payment and a 2,000 sat fee must allocate the remaining 18,000 sat to another output or leave it in the fee. The recipient output and change output are peers in transaction serialization, and their ordering carries no consensus meaning. After confirmation, the change is a new UTXO with its own outpoint, confirmation state and future spending cost—not a fragment left inside the old UTXO. [Bitcoin Developer Guide — Transactions]

Coin selection jointly chooses inputs, fee and possible change. An exact-match set can avoid a change output; otherwise the wallet compares the remainder with the cost of creating and later spending it. Bitcoin Core's funding RPC can add at most one change output and reports its position, while send-all intentionally has none. Manual coin control changes the candidate inputs and therefore the change value, but selecting more coins than needed does not preserve them: every selected input is consumed. Always review the final inputs, recipient amounts, fee and change, not only the payment field. [Bitcoin Core — Coin Selection Implementation] [Bitcoin Core RPC — fundrawtransaction] [Bitcoin Optech — Coin Selection]

HD wallets normally derive receiving scripts on an external branch and change on an internal branch. BIP44 defines change=0 as external and change=1 as internal, yielding paths such as m/84'/0'/0'/0/i and m/84'/0'/0'/1/i for a native-SegWit account. This is an application convention, not a consensus rule, and descriptor wallets can express other policies. A fresh internal address avoids obvious address reuse; sending change back to the original address remains valid but links activity and enlarges the damage if that address later becomes identifiable. [BIP 32 — Hierarchical Deterministic Wallets] [BIP 44 — Multi-Account Hierarchy]

An output descriptor binds the script type, keys, origins and derivation wildcard that define wallet ownership. Separate descriptors such as wpkh([fingerprint/84h/0h/0h]xpub…/0/*) and …/1/* describe receive and change; BIP389 multipath syntax can combine branches. The internal flag tells wallet software which active descriptor supplies change, but does not alter the generated script. Backing up only a seed without the account, script type and derivation policy can make valid change invisible during recovery even though the keys still exist. [BIP 380 — Output Script Descriptors] [BIP 389 — Multipath Descriptor Key Expressions] [Bitcoin Core — Output Descriptors]

A block reveals values and scriptPubKeys, not labels such as payer, merchant or change. Wallets identify their own change from their derivation records; explorers and analysts guess. Output order is not a reliable label, nor is “the second output.” A transaction can have no change, one change output, multiple self-controlled outputs created by specialized software, or outputs contributed by several parties. Change is therefore a wallet-relative classification: the same output can be recognized by its owner while remaining ambiguous to everyone else. [Bitcoin Developer Guide — Transactions]

Common guesses mark the output matching the inputs' script type, the non-round amount, a fresh address, or the value that best fits input arithmetic as change. These signals often work on ordinary two-output payments and can cluster later spends, but each has counterexamples. BIP78 Payjoin deliberately breaks common-input ownership and script-type or round-amount change heuristics; CoinJoin, batched payments and self-transfers add ambiguity. Heuristic attribution should carry confidence and corroboration, never be presented as protocol proof or legal ownership. [BIP 78 — Payjoin] [Meiklejohn et al. — A Fistful of Bitcoins]

Dust is a node relay-policy calculation based on output type, the estimated size needed to spend it and a configurable dust relay feerate; it is not one universal satoshi value or a consensus ban. A wallet can also reject change well above dust when creating and later spending that output is expected to cost more than its value. That economic threshold depends on the current fee rate, a long-term fee estimate and script size. Suppressing change raises the immediate fee, while creating tiny change can strand value or make future consolidation expensive. [Bitcoin Core — Transaction Relay Policy]

In a PSBT, output BIP32 derivation fields let a hardware or offline signer derive a proposed output and check that it returns to the same wallet policy. BIP174 describes single-key and multisig change detection; matching only one local key is insufficient when the input policy is multisig. A malicious coordinator can replace change with its own output or disguise the remainder as an excessive fee. The signer should independently verify recipient outputs, total fee and every claimed change output on a trusted display before authorizing signatures. [BIP 174 — Partially Signed Bitcoin Transaction Format]

Replace-by-fee (RBF) changes transaction economics before confirmation. Bitcoin Core's bumpfee may pay the higher fee by reducing an existing change output, adding inputs, or creating change when necessary; if reduced below policy or economic thresholds, change can disappear. Spending an unconfirmed change output creates a descendant whose validity depends on the parent replacement, and CPFP uses a wallet-controlled output to raise package feerate. Do not treat an unconfirmed change txid/outpoint as final until replacements have settled. [Bitcoin Core RPC — bumpfee]

A complete recovery needs the seed or signing keys plus the receive and internal descriptors, key origins, account and network, script policy, derivation ranges and an adequate scan start. Missing /1/* commonly produces an apparently short balance because received change is not discovered. In multisig, preserve every cosigner xpub, threshold and ordering for both branches. Test restoration by matching known receive and change scripts, reconstructing the UTXO set, creating a PSBT and verifying change on each signer before relying on the recovered wallet. [BIP 32 — Hierarchical Deterministic Wallets] [BIP 380 — Output Script Descriptors] [BIP 389 — Multipath Descriptor Key Expressions]