Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Privacy & Analysis

Address reuse, and why it costs more than it looks

An address is not an account, but it behaves like one the moment it is used twice. Every payment to the same address is written into the same history, and that history is what an observer reads when they try to work out who is behind it.

Protocol referenceSource: Bitcoin Core, avoid_reuse wallet flagNo market data is used on this page; the behaviour described follows Bitcoin Core's wallet documentation.

What reuse publishes

A Bitcoin address is a script hash, and the ledger records payments to it as outputs that name that script. Nothing prevents the same script from appearing in many outputs, and nothing marks those outputs as belonging together. But they are trivially grouped by anyone reading the chain: the outputs share a script, so they share a destination, and the total received at that destination is public. The moment an address is used twice, an observer has a running account statement for it.

The damage compounds when the address is spent. If the outputs received at one address are spent together, the common-input heuristic links them, which the observer already knew. The real problem is what happens next: the change from that spend goes to a new address, and if the owner later spends that change alongside coins from elsewhere, the whole set is merged into one cluster. The reused address becomes the anchor that ties unrelated holdings together, and the tie is permanent.

Bitcoin's own documentation is unambiguous about the remedy. The project advises using a new address for every payment received, and notes that because the chain is permanent, something that is not traceable today may become trivial to trace later. That second point is the one people underestimate. Reuse is not a problem that announces itself at the time; it is a liability that matures when some future piece of off-chain information connects the address to a person.

How wallets cause it

Most reuse is not a decision. It is a default. A wallet that shows one receiving address and never rotates it will be reused by every payer, because the payer has no reason to ask for a new one. This is common in older software, in some exchange deposit flows, and in any setup where an address is published once and left in place — a donation page, a shop's payment details, a signature on a forum post. The owner may never spend twice from it, but the payers have already published the link.

A second source is the receiving side of a payment request. If a merchant issues the same address to every customer, the merchant's revenue is public in aggregate, and each customer's payment is visible to every other customer. The merchant may consider this acceptable; the customers rarely do, and they have no way to opt out. Bitcoin Core's wallet addresses this on the sending side with the avoid_reuse flag, which refuses to spend from an address that has already been used, and with avoidpartialspends, which groups outputs by destination so that a reused address is swept whole rather than partially. Both are privacy measures with a fee cost, and both are documented as such.

A third source is restoration. A wallet restored from a seed phrase regenerates its addresses in derivation order, and if the software does not track which ones have been used, it may hand out an address that already has history. This is why gap limits and address discovery exist, and why a restored wallet can appear to have "forgotten" that an address was used. The change addresses page covers the derivation-order problem in more detail.

The trade-off, stated plainly

Avoiding reuse is not free. A wallet that refuses to spend from a used address may have to select a larger set of inputs, which makes the transaction bigger and the fee higher. Bitcoin Core's documentation of avoidpartialspends says exactly this: the privacy improvement comes at the cost of a less optimal coin selection and possibly more inputs than strictly necessary. For a wallet with many small outputs, the difference can be material.

There is also a usability cost. Rotating addresses means the payer must be given a fresh one each time, which requires the receiving software to generate and communicate them. For a person accepting a single payment this is trivial; for a business with an invoicing system it is an integration. The reason to accept the cost is that the alternative is not a smaller version of the same problem. It is a permanent public record of every payment to that address, joined to whatever else the owner does.

The practical rule is the one the project states: one address, one payment. Where that is impossible, the next best thing is to keep the reused address isolated — never spend its outputs together with coins from elsewhere, and treat anything received there as already public. The coin control page explains how to enforce that isolation deliberately.

Sources