Address Reuse

What Is Address Reuse?

Address reuse is the practice of receiving Bitcoin to the same address more than once. Bitcoin addresses are designed as single-use invoice identifiers: each payment should go to a fresh address derived from the same wallet. Reuse works because the protocol does not enforce single-use at the consensus level, but it degrades privacy and security for everyone involved in the transaction.

The problem is analogous to giving every person who emails you the same reply-to address versus giving each sender a unique alias. With a single address, anyone who learns your identity through one transaction can trace every other payment you have ever received or sent from that address on the public blockchain.

Despite being widely recognized as harmful, address reuse remains common. Research from BitMEX found that around 50% of transaction outputs were sent to previously used addresses, with reuse rates peaking near 75% in 2013 before gradually declining as HD wallets became standard.

How It Works

To understand why address reuse is dangerous, consider how Bitcoin addresses protect their owners before and after spending.

Before Spending: Hash Protection

In P2PKH and P2WPKH address formats, the address encodes a hash of the public key (RIPEMD-160 of SHA-256), not the key itself. An attacker who knows only the address cannot derive the public key. This hash layer provides a buffer against potential future attacks on elliptic curve cryptography.

# P2PKH scriptPubKey structure
OP_DUP OP_HASH160 <pubKeyHash_20bytes> OP_EQUALVERIFY OP_CHECKSIG

# P2WPKH scriptPubKey structure
OP_0 <pubKeyHash_20bytes>

# In both cases, the public key is hidden behind HASH160

After Spending: Public Key Exposed

When you spend from a P2PKH or P2WPKH address, the transaction must include the full public key alongside the signature in the scriptSig or witness data. This permanently records the public key on the blockchain.

If you then receive new funds to the same address, those funds sit at an address whose public key is already publicly known. The hash-based protection layer is gone. Any future cryptographic breakthrough (including quantum computing via Shor's algorithm) that can derive a private key from a public key would put those funds at risk.

The Taproot Exception

P2TR (Taproot) addresses work differently. The output directly encodes a 32-byte x-only tweaked public key rather than a hash. This means the public key is derivable from the address itself, even before spending. Taproot made this tradeoff deliberately: it gains privacy benefits (key-path and script-path spends look identical) and enables Schnorr signature aggregation, but sacrifices pre-spend key hiding. For a deeper comparison of address formats, see the Bitcoin address types guide.

Privacy Consequences

Address reuse is the single most damaging privacy mistake a Bitcoin user can make. Its effects extend beyond the individual reuser to everyone who transacts with them.

Transaction Linking

Every payment to a reused address is permanently and publicly connected on the blockchain. If a chain analysis firm, exchange, or government ties even one transaction to a real-world identity (through KYC records, IP address correlation, or merchant data), they can attribute every other transaction to that same identity.

Change Detection

When analysts see a reused address as one output in a transaction, they can reliably conclude it is the payment output rather than the change output. The other output is therefore change, which traces back to the sender. This cascading inference across the transaction graph is a core technique in blockchain surveillance: what researchers have called "the unreasonable effectiveness of address clustering."

Harming Others' Privacy

Address reuse does not only affect the person reusing addresses. Everyone who sends to or receives from a reused address has their transaction recorded as being associated with that known entity. Even privacy-conscious users who practice careful coin control can have their efforts undermined by transacting with someone who reuses addresses.

Enabling Dust Attacks

In a dust attack, an adversary sends tiny amounts to known addresses. If the victim's wallet includes these dust UTXOs as inputs in a future transaction, the common-input-ownership heuristic links the victim's other addresses to the known address. Address reuse makes dust attacks more effective because the target address is already public and associated with prior activity.

Why It Still Happens

Despite widespread guidance against it, address reuse persists for several practical reasons:

• Exchange deposit addresses: many exchanges assign users a single deposit address for convenience, which gets reused with every deposit.
• Donation addresses: organizations and individuals publish a single Bitcoin address on websites, social media, or forum signatures for receiving tips and donations.
• QR codes on physical media: addresses printed on merchandise, posters, or business cards cannot be rotated after printing.
• User habits: people unfamiliar with Bitcoin's design treat addresses like bank account numbers, sharing the same one repeatedly.
• Legacy software: older wallets did not automatically generate new receiving addresses, and before BIP-32 HD wallets (2013), generating new addresses meant managing separate key backups.

Wallet Features That Prevent Reuse

Modern Bitcoin wallets implement several mechanisms to eliminate or reduce address reuse automatically, without requiring users to understand the underlying problem.

HD Wallets (BIP-32 / BIP-44)

Hierarchical deterministic wallets derive an unlimited tree of key pairs from a single master seed, as defined in BIP-32. The BIP-44 standard organizes these into separate chains for receiving and change addresses, using the derivation path structure:

m / purpose' / coin_type' / account' / change / address_index

# Example: first external receiving address (BIP-84, P2WPKH)
m / 84' / 0' / 0' / 0 / 0

# Example: first change address
m / 84' / 0' / 0' / 1 / 0

Good wallet software automatically increments the address index for each new receiving request, so the user never sees the same address twice. The gap limit (default 20) defines how many consecutive unused addresses a wallet scans during recovery before assuming no more funds exist.

Bitcoin Core's avoid_reuse Flag

Bitcoin Core v0.19.0 introduced the avoid_reuse wallet flag (PR #13756). When enabled, the wallet tracks which addresses have been previously spent from and excludes their UTXOs from coin selection by default. Combined with the -avoidpartialspends option (v0.17.0), this mitigates forced address reuse from dust attacks by spending all UTXOs to a given address together when it must spend from a reused address.

BIP-47 Reusable Payment Codes

BIP-47 lets users publish a static "payment code." Senders use a notification transaction and an ECDH key exchange to derive unique addresses for each payment. The recipient's wallet detects these payments without any address reuse occurring on-chain. This solves the donation address problem: a user can publish one identifier that resolves to fresh addresses every time.

Silent Payments (BIP-352)

Silent payments improve on BIP-47 by eliminating the notification transaction entirely. The sender derives a unique on-chain address for every payment using the receiver's static identifier and ECDH, with no interaction required. An input_hash commitment ensures unique addresses even when the sender reuses the same inputs. For a detailed comparison, see the silent payments deep dive.

The UX Tradeoff

The tension between privacy best practices and user experience is real. Users accustomed to bank account numbers or email addresses expect a single, permanent identifier. Seeing a different receiving address each time can cause confusion or anxiety about whether funds were sent correctly.

HD wallets largely solve this from the technical side: a single seed phrase backs up all derived keys, so the user only needs to secure one backup regardless of how many addresses the wallet generates. The remaining UX challenge is educational: helping users understand that their wallet manages addresses automatically and that a new address does not mean a new wallet.

Protocols like silent payments and BIP-47 address the donation and tip-jar use case by providing a stable, publishable identifier that resolves to unique addresses under the hood. As these protocols gain wallet support, the UX gap between "one address forever" and "fresh address every time" continues to narrow.

Quantum Computing Implications

Address reuse amplifies the risk from future quantum computers. The HASH160 protecting unspent P2PKH and P2WPKH outputs is resistant to quantum attacks (Grover's algorithm provides only a quadratic speedup against hash functions). However, a quantum computer running Shor's algorithm could derive a private key from an exposed public key.

For non-reused addresses, the public key is only exposed briefly during the transaction confirmation window. For reused addresses where funds remain after a spend, the public key is permanently on-chain with funds sitting behind it: a static target for any future cryptographic attack. Deloitte estimated approximately 2.5 million BTC stored in reused P2PKH addresses with exposed public keys.

Best Practices

Avoiding address reuse is one of the simplest and most impactful steps any Bitcoin user can take to protect their privacy and security:

1. Use a modern HD wallet that generates a new receiving address for every transaction automatically
2. Never manually copy and reuse an old receiving address from your transaction history
3. Enable avoid_reuse in Bitcoin Core to prevent spending from addresses that have already been used
4. Practice coin control to avoid consolidating UTXOs from different contexts into the same transaction
5. For donation or tip-jar use cases, adopt silent payments or BIP-47 payment codes instead of publishing a static address
6. Be cautious with dust received at previously used addresses: do not spend it without understanding the implications for your privacy

Relevance to Layer 2 Solutions

Layer 2 protocols like the Lightning Network and Spark inherently reduce address reuse on the base chain. Lightning payments route through HTLCs without creating new on-chain outputs for each transaction, while Spark uses off-chain transfers that avoid base-layer address exposure entirely. By moving frequent, smaller payments off-chain, these protocols reduce the footprint of reusable addresses on the public blockchain. For users concerned about on-chain privacy, combining HD wallet best practices with a layer 2 solution provides the strongest protection.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.