A gold Bitcoin coin standing on edge on a dark reflective surface, with a fingerprint pattern etched into the coin's face and also revealed in blue on the surface beside it
Original illustration generated with AI (Adobe Firefly) — it does not represent real data.

BIP69 Was Meant to Hide Your Wallet. It Became a Fingerprint.

A transaction's input ordering leaks which software built it. BIP69 proposed a deterministic ordering so that every wallet would look alike. Adoption was partial. The result is that following the standard now identifies you about as well as ignoring it did.

The ordering problem, and its punchline

We have companion pieces on checking whether your wallet is traceable, on address reuse, and on why consolidating UTXOs is irreversible.

Nothing in the consensus rules dictates the order of inputs and outputs in a transaction. Wallet authors pick one. Some preserve selection order, some shuffle, and some sort deterministically: inputs by previous transaction id then index, outputs by amount then scriptPubKey. That is BIP69.

The proposal existed precisely to erase this signal. Universal adoption would have made ordering meaningless as evidence. Partial adoption did the opposite, and split the population into "sorts lexicographically" and "doesn't" — a clean binary that costs an observer nothing to evaluate.

There is a general lesson buried in there about privacy tooling, and it isn't a comfortable one: a defence adopted by a minority marks the minority. It applies well beyond transaction ordering.

The other tells

Ordering is one signal among several, and none of them require looking at a single address:

  • nLockTime. Some wallets set it to the current block height as anti-fee-sniping protection rather than leaving it at zero. Functionally irrelevant to the user, cleanly discriminating to an observer.
  • Transaction version. Two values are standard. Wallets differ. Users never choose.
  • RBF signalling. Always on, never on, or user-configurable and therefore left at whatever the default was.
  • Change output script type. If the payment goes to one address format and the change returns to another, identifying which output is yours takes no heuristic at all. You just read it.

Why good address hygiene doesn't cover this

This is the part worth internalising. Address hygiene defeats linkage through a repeated identifier. Fingerprinting operates on transaction shape, which survives perfectly well when every address is fresh.

Two-layer diagram: the address layer, where linkage comes from a repeated identifier, and the construction layer, where linkage comes from transaction shape
Original diagram: address hygiene acts on the upper layer. The wallet fingerprint lives in the lower one and passes through untouched.

The practical consequence shows up when you move between wallets. Spend outputs that passed through different software in the same chain, and the sequence of fingerprints narrates the migration. On its own it proves nothing. As context it does plenty, and context is what turns scattered transactions into a profile.

What we look for, and what we don't

Our privacy audit checks for exchange linkage, address reuse and consolidations that merge origins which should have stayed apart. It does not identify signing software, and there are no plans for it to.

Saying that in an article about fingerprinting is deliberate. The alternative is letting you assume a coverage we don't have — which is the failure mode this whole project is built to avoid.

If you want to start with what we do cover, run one of your addresses through the privacy audit.

Last updated: 2026-08-02