Change addresses, and the information they leak

The oldest signal is script type. If a transaction spends P2PKH inputs and creates one P2PKH output and one bech32 output, the analyst assumes the output matching the inputs is the change, because a wallet tends to pay change to an address of the same type it spends from. Wallets that use a distinct change type, or that upgrade everything to the newest type, remove this signal. The address types page covers the families and their prefixes.

The second signal is value. A payment is often a round number and the change is whatever is left, so the non-round output is assumed to be the change. This is a weak signal that fails whenever the payment is not round, and it is defeated entirely by wallets that deliberately randomise the amounts. The third signal is behaviour: if an output is later spent in a transaction with other outputs the analyst already attributes to the sender, the link is confirmed after the fact. This is the strongest of the three and the slowest, because it requires waiting for the next spend.

BIP 69 addresses a related leak. Before it, wallets ordered inputs and outputs however their code happened to, and the resulting patterns were a fingerprint: the BIP's own motivation notes that many wallets placed spending outputs first and change outputs second, leaking information about both parties' finances. The proposal is a deterministic lexicographic ordering of inputs by previous transaction hash and output index, and of outputs by value and script. It is informational rather than consensus, but it removes a class of passive observation at no cost to the transaction's function.

An HD wallet derives its addresses in sequence from a seed, and the sequence is deterministic. That is what makes restoration possible: given the seed, the wallet can regenerate every address it ever handed out. It also means that the addresses a wallet uses are not independent random values but consecutive points on a known path. An observer who learns one address cannot compute the next — that would require the extended public key — but an observer who obtains an extended public key can derive every non-hardened address beneath it.

BIP 32 is explicit about this asymmetry. Knowing an extended public key allows reconstruction of all descendant non-hardened public keys, and the specification warns that a parent extended public key combined with any non-hardened private key descending from it is equivalent to knowing the parent extended private key. This is why hardened derivation exists and why it is used at the account level. For privacy, the practical consequence is that an extended public key is a much more sensitive object than a single address: it is a map of every address the wallet will use.

There is a smaller leak that does not require any key material. A wallet that hands out addresses in strict sequence publishes the order in which it received payments, because the addresses appear on the ledger in that order. If two addresses from the same wallet are ever linked — by a shared spend, by a common counterparty, by anything — the sequence tells the analyst which payment came first. The address reuse page covers the case where the sequence is not even needed, because the same address was used twice.