Bitcoin Wallet Fingerprinting: On-Chain Traces Guide

How Wallets Leave Fingerprints On-Chain

Every Bitcoin wallet makes implementation decisions when constructing a transaction: how to select inputs, where to place the change output, which address format to use, what fee rate to target, how to set nLockTime, and whether to signal replace-by-fee. These choices create patterns that chain analysis firms use to identify which software created a transaction, cluster addresses into entities, and trace funds across hops.

Research by Ishaana Innam analyzed eight major wallets and identified over 30 distinct traits that serve as fingerprints, achieving roughly 50% accuracy in identifying the originating wallet from a single transaction. Separate work by David Corral Urbano at the Universitat Autònoma de Barcelona studied 14 wallets and improved identification accuracy from 18% to 45% using updated heuristics. The key insight from both studies: ruling out wallets based on the absence of fingerprints is often more effective than identifying wallets by their presence.

Fingerprinting Heuristics by Wallet

The following table summarizes the most important fingerprinting traits across widely used Bitcoin wallets. Each trait is observable on-chain without any off-chain data.

Address Type Fingerprints

The address format a wallet uses is one of the strongest fingerprints. Most modern wallets default to bech32 P2WPKH addresses, but support for older formats varies. When a transaction mixes input types (for example, P2SH-wrapped SegWit inputs with a native SegWit change output), the mismatch reveals information about the wallet's history and configuration.

Taproot (P2TR) adoption adds a new dimension. A wallet spending from a P2TR input and sending change to a P2TR output is identifiable as running software released after late 2021. More importantly, P2TR makes multisig addresses indistinguishable from single-sig on-chain thanks to Schnorr signature aggregation, a significant privacy improvement over P2WSH multisig where the quorum is exposed in the witness.

Coin Selection Algorithms

How a wallet chooses which UTXOs to spend is a major fingerprint because different algorithms produce different transaction shapes.

Bitcoin Core (v27+) runs four algorithms in parallel and selects the result with the lowest "waste metric" score: Branch and Bound (BnB) searches for an exact-match input set that avoids creating change; Knapsack approximates the target amount; Single Random Draw (SRD) randomly selects UTXOs; and CoinGrinder (added in v27.0) minimizes total input weight at fee rates above 30 sat/vB. Bitcoin Core also accepts negative effective-value inputs, meaning it will spend UTXOs where the fee exceeds the UTXO's value.

Electrum takes a different approach: it selects only positive effective-value inputs (unless the user enables SEND_MAX) and historically favors the oldest UTXOs first. Ledger Live also uses a FIFO strategy (oldest UTXOs first) and does not shuffle inputs after selection. These patterns create observable differences in transaction structure. For hands-on UTXO management strategies, see our UTXO management guide.

Change Output Detection

Identifying which output is change and which is the payment is one of the most valuable heuristics in chain analysis. Several signals make this possible:

• Address type matching: if all inputs are P2WPKH and one output is P2WPKH while the other is P2TR, the P2WPKH output is likely change (it matches the wallet's input type)
• Round number analysis: payment amounts tend to be round numbers (0.1 BTC, 0.05 BTC); the non-round output is likely change
• Electrum's documented behavior specifies that the change output type always matches the input type, making this heuristic especially reliable for Electrum transactions
• RBF fee bumping: when a transaction is replaced via RBF, the output whose amount decreases is the change output (the higher fee is deducted from change)
• Subsequent spending: change outputs spent with the same wallet fingerprint confirm the identification retroactively

Bitcoin Core's Branch and Bound algorithm sometimes produces transactions with no change output at all. A changeless transaction leaks no information about which output belongs to the sender, making it the ideal case for privacy.

Input and Output Ordering

BIP69 defines a deterministic lexicographic ordering for inputs and outputs: inputs sorted by previous txid (reversed byte order) then output index; outputs sorted by amount (ascending) then scriptPubKey. The goal was to standardize ordering so that no wallet would stand out, but adoption was uneven, which turned BIP69 compliance into a fingerprint of its own.

Electrum and Trezor Suite implement BIP69 by default. Bitcoin Core and Wasabi do not: they use random shuffling of both inputs (merged in PR #12699) and outputs (PR #12709). A random two-output transaction matches BIP69 ordering 50% of the time by chance, so consistent BIP69 compliance across multiple transactions from the same wallet is statistically identifiable. Many privacy researchers now argue that random ordering is superior to BIP69 for privacy precisely because it avoids this deterministic pattern.

Fee Estimation Patterns

The fee estimation algorithm a wallet uses produces characteristic fee rate distributions. Bitcoin Core uses a history-based algorithm that tracks confirmed transactions across three time horizons with exponential decay: short (half-life 18 blocks), medium (half-life 144 blocks), and long (half-life 1,008 blocks). It offers CONSERVATIVE (default) and ECONOMICAL modes.

Electrum offers three modes: ETA (history-based, tends to overestimate), Mempool (examines current mempool state for more accurate estimates), and Static (user-defined fixed rate). These different approaches produce distinct fee rate clusters. A transaction paying a fee rate that closely matches Bitcoin Core's conservative estimate for 6-block confirmation is more likely from Bitcoin Core than from Electrum's mempool-based estimator, which adjusts more quickly to short-term fee changes.

nLockTime and Anti-Fee-Sniping

Anti-fee-sniping sets nLockTime to the current block height to prevent miners from profiting by reorganizing recent blocks. The implementation varies significantly across wallets, creating one of the more reliable fingerprints.

BIP326 specifies that wallets spending Taproot inputs should randomly alternate between nLockTime and nSequence-based (BIP68) anti-fee-sniping. This makes regular on-chain spends indistinguishable from Lightning or CoinSwap channel closures. BIP326 is implemented in BDK (the Bitcoin Development Kit).

RBF Signaling and Sequence Numbers

Opt-in RBF is signaled via BIP125 by setting any input's nSequence to less than 0xfffffffe (MAX-1). The specific nSequence value used varies by wallet: Bitcoin Core and Electrum both set nSequence to MAX-1 or MAX-2, while Wasabi (since v2.0.4) treats all transactions as full-RBF replaceable by default.

Since Bitcoin Core v29, full-RBF is hardcoded (the mempoolfullrbf option was removed). This means any unconfirmed transaction can be replaced regardless of signaling. However, the nSequence value in the original transaction still serves as a wallet fingerprint because it reflects the software's default setting at the time of construction.

Low-R Signature Grinding

Low-R grinding regenerates ECDSA signatures until the R value falls in the lower half of the range, saving one byte per signature on average. This applies only to legacy and SegWit v0 transactions (not Taproot, which uses Schnorr signatures with fixed-size 64-byte outputs).

Bitcoin Core has implemented low-R grinding since July 2018. Electrum added it via PR #5820. C-Lightning and LDK also implement it. The presence of a high-R signature can rule out Bitcoin Core and similar wallets: this is a strong negative fingerprint. A transaction with all low-R signatures is consistent with Core but not proof of it, while a single high-R signature definitively rules Core out.

Privacy-Enhancing Transaction Types

Several wallets implement specialized transaction types designed to resist fingerprinting, though these constructions are themselves identifiable:

• Whirlpool (Samourai/Sparrow): ZeroLink CoinJoin with exactly 5 participants per mix and fixed denominations, creating 1,496 possible interpretations per mix
• WabiSabi (Wasabi): CoinJoin with variable amounts and dozens of participants per round
• STONEWALL (Samourai/Sparrow): a "fake CoinJoin" using only the sender's UTXOs to create equal-value outputs and increase transaction entropy
• PayJoin: both sender and receiver contribute inputs, breaking the common-input-ownership heuristic

Research has shown that CoinJoin transactions from both Wasabi and Samourai can be identified with near-100% accuracy using threshold heuristics and machine learning. The transactions themselves are recognizable; the privacy benefit comes from making post-mix spending harder to trace. For a broader look at these techniques, see our guide on Bitcoin privacy techniques.

Reducing Your Wallet Fingerprint

Complete fingerprint elimination is not practical, but several steps reduce exposure:

• Use coin control to manually select inputs and avoid unnecessary UTXO mixing
• Avoid address reuse, which trivially links transactions regardless of other fingerprints
• Prefer Taproot addresses where supported: P2TR hides multisig complexity and enables BIP326 anti-fee-sniping
• Use wallets that implement random input/output ordering rather than deterministic BIP69 sorting
• Run your own Bitcoin node to avoid leaking transaction timing to third-party servers
• Consider silent payments for receiving funds without publishing reusable addresses

Layer 2 protocols offer structural privacy advantages. Transactions on the Lightning Network or Spark are not broadcast to the Bitcoin base chain during normal operation, making on-chain fingerprinting irrelevant for the majority of payment activity. Only channel opens, closes, and on-chain settlements leave a trace. For privacy-sensitive users, moving routine payments off-chain is one of the most effective mitigations available.

Frequently Asked Questions

What is Bitcoin wallet fingerprinting?

Wallet fingerprinting is the process of identifying which software created a Bitcoin transaction by analyzing its on-chain characteristics. Every wallet makes implementation choices (coin selection algorithm, address types, output ordering, fee estimation, nLockTime values) that leave detectable patterns. Chain analysis firms use these patterns to cluster addresses, trace funds, and attribute transactions to specific wallet software or entities.

Can blockchain analysts identify which wallet I use?

With a single transaction, research shows roughly 50% accuracy in identifying the originating wallet. Accuracy improves with multiple transactions from the same wallet because patterns become statistically significant. Negative fingerprints (ruling out wallets that cannot have produced a given transaction) are especially reliable. For example, a high-R ECDSA signature definitively rules out Bitcoin Core, and consistent BIP69 ordering rules out wallets that use random shuffling.

Does using Taproot improve privacy against fingerprinting?

Taproot (P2TR) provides several privacy improvements. Schnorr signature aggregation makes multisig transactions indistinguishable from single-sig on-chain. BIP326 enables wallets to alternate between nLockTime and nSequence-based anti-fee-sniping, making regular transactions look like channel closures. However, Taproot adoption is still growing, so using P2TR currently identifies you as running post-2021 software, which narrows the set of possible wallets.

What is BIP69 and why does it affect privacy?

BIP69 defines a deterministic lexicographic ordering for transaction inputs and outputs. Its goal was to standardize ordering across all wallets so none would stand out. In practice, only some wallets adopted it (Electrum, Trezor) while others use random ordering (Bitcoin Core, Wasabi). This split means BIP69 compliance is itself a fingerprint: a transaction that consistently matches BIP69 across multiple spends is likely from Electrum or Trezor rather than Bitcoin Core.

How does coin selection affect transaction privacy?

Different coin selection algorithms produce different transaction shapes. Bitcoin Core's Branch and Bound algorithm can produce changeless transactions (no change output), which are ideal for privacy because both outputs look like payments. Electrum's oldest-first selection with positive-effective-value-only inputs produces a recognizable pattern. Ledger Live's FIFO ordering without post-selection shuffling is also distinctive. Using coin control to manually select inputs can break these patterns.

Do CoinJoin transactions prevent wallet fingerprinting?

CoinJoin transactions from Wasabi (WabiSabi) and Samourai (Whirlpool) can be identified with near-100% accuracy based on their distinctive structure. The privacy benefit is not in hiding the CoinJoin itself but in making post-mix outputs difficult to trace. After a CoinJoin, the equal-value outputs are ambiguous: an observer cannot determine which participant controls which output. However, if post-mix spending reintroduces wallet fingerprints (through coin selection patterns or address reuse), the privacy gains can be partially or fully undone.

Does using a hardware wallet change my fingerprint?

Hardware wallets like Trezor and Ledger primarily handle key storage and signing. The transaction fingerprint depends more on the companion software (Trezor Suite, Ledger Live, Sparrow, Electrum) than on the hardware device itself. Connecting a Ledger to Sparrow instead of Ledger Live will produce transactions with Sparrow's fingerprint, not Ledger Live's. The signing device influences whether low-R grinding is applied, but all other structural fingerprints come from the software constructing the transaction.

This guide is for informational and educational purposes only. It does not constitute financial or legal advice. Fingerprinting heuristics described here are based on publicly available research and wallet source code. Wallet software is updated frequently, and behaviors may change between versions. Always verify current wallet behavior against the latest release documentation before relying on these characterizations.