Address reuse and quantum exposure

Most Bitcoin addresses are built to hide their public key until the moment they spend. That protection holds exactly once. Spend from an address, receive on it again, and the new coins sit on a key that is already public, permanently. Address reuse is usually filed under privacy. It is also, by a wide margin, the most common way coins end up exposed to a future quantum attack. This article explains the mechanism, how big the reused set is, how to tell whether one of your addresses is in it, and what to do calmly if it is.

What a spend reveals

An ordinary single-signature address, legacy 1… or SegWit bc1q…, is a 20-byte hash of a public key. The chain stores that hash and nothing else. To spend the coins, the owner has to prove they hold the matching private key, and the proof needs two things in the spending transaction: a signature, and the public key itself, so that every node can hash it, check it matches the address, and verify the signature against it.

From that block on, the key is public. It is not something a node forgets or a wallet can take back. It is part of the permanent record, readable by anyone who downloads the chain, now or in twenty years.

For a script address (3… or a 62-character bc1q…), the same thing happens one level up: the address is a hash of a script, and spending reveals the whole script, including every public key in it. A 2-of-3 multisig that spends once has put all three keys on the chain, not just the two that signed.

None of this matters against today's computers. Deriving a private key from a public key on Bitcoin's curve is infeasible for classical hardware. It matters because Shor's algorithm, run on a large enough error-corrected quantum computer, would make that derivation practical, and a hash gives it nothing to work with.

What “reuse” actually means here

For privacy, any reuse is bad: two payments to the same address link the two senders, the amounts and the timing for anyone watching. For quantum exposure the question is narrower. What matters is whether coins sit on an address whose key has already been revealed. That happens in three common ways.

• Receive after spend. An address spends, and later someone pays it again. A donation address, an exchange withdrawal whitelist entry, an invoice template that never got updated. The new coins arrive on a public key.
• Partial spend. An address receives several payments, and the owner spends only one of those outputs. The spend reveals the key, and the outputs left behind are now on it. This one surprises people, because they never sent anything to the address after spending.
• Change sent back to the same address. Some older wallets and many custodial systems return the change from a payment to the address it came from. Every such payment leaves the remaining balance on a freshly revealed key.

The opposite case is also worth stating, because it is the good news: an address that has received many times but never spent is still hashed. It has a privacy problem, but its key is not on the chain. And an address that spent everything and now holds nothing exposes nothing either, until someone sends to it again.

How much bitcoin sits on reused addresses

Nobody has an exact figure for the whole chain, and we will not invent one. What can be said with sources:

• BIP-361 (Lopp et al., a draft proposal for a post-quantum migration) states that as of 1 March 2026 over 34% of all bitcoin had revealed a public key on-chain, and names long-range attacks due to address reuse as one of the problems it is meant to address. That figure covers every cause together: reuse, Taproot and the early pay-to-public-key outputs.
• Our own report on the 100 largest addresses, taken at block 965,290 on 3 September 2026, found 67 of them exposed. Of those 67, 65 were hashed addresses that had spent at least once, holding about 2.21 million BTC between them. Only 2 were Taproot outputs, holding about 30,000 BTC.

The second point is the one people do not expect. Public discussion of Bitcoin and quantum computers tends to focus on Taproot, because it publishes the key by design. Among the largest balances, the old habit of paying the same address over and over matters far more.

Why large holders reuse addresses

The biggest reused addresses are almost all exchange and custodian cold wallets, and the reason is operational, not careless. A fixed cold-wallet address is easy to whitelist, easy to audit, easy to publish in a proof-of-reserves statement, and easy to recognise in internal tooling. Rotating to a new address after every withdrawal means more key management, more procedures and more places for a human to make a mistake. For years the trade looked obviously worth it, because the only cost was privacy, and an exchange's cold wallet is not private anyway.

Quantum exposure changes the cost side of that trade without changing the benefit side. That is a decision for each custodian to make with its own numbers. For an individual holder the lesson is narrower: if your coins are with a custodian, they are on whatever addresses the custodian chose, and no scanner can tell you which ones those are.

A quieter version: the same key behind different addresses

There is a variant that is easy to miss. The same public key can sit behind more than one address format: a legacy 1… address, a nested SegWit 3… address and a native bc1q… address can all be derived from one key. Spending from any one of them reveals the key for all of them, because it is the same key. A wallet that has, at some point, been restored under a different address type and then received coins on both can end up here without the owner noticing.

We mention this because our own scanner does not catch it. ShorWatch checks each address on its own: has this address ever spent? It does not search for the same key behind a sibling address. If you know you have used one key under several formats, treat them as one address for this purpose.

How to tell whether an address has been reused

The test is simple, and you can do it by hand on any block explorer: open the address and look for an outgoing transaction, one where the address appears as an input. If there is none, the key has not been revealed and the balance is protected at rest. If there is one, any balance it holds now is on a visible key, no matter when it arrived.

For one address that is quick. For a wallet with dozens of addresses it is tedious, which is the job the ShorWatch scanner does: paste an address, or an extended public key for a whole wallet, and it checks every address for a previous spend, including unconfirmed spends in the mempool, and shows the balance on each side of the line.

What to do about it

Nothing here is urgent, and none of it should be done in a hurry. It is a question of where long-term coins sit.

1. Stop reusing, starting now. Any modern HD wallet will give you a fresh receive address every time you ask, and sends change to a new address automatically. If you publish a static address for donations or invoices, know that it is exposed from its first spend onward, and rotate it when you can.
2. When you spend from an address, spend all of it. If you are going to reveal the key anyway, avoid leaving outputs behind on it. Most wallets let you select the coins for a transaction; sending the remainder to a fresh address in the same transaction leaves nothing on the revealed key.
3. For balances already on a reused address, decide with numbers. One transaction moves them to a never-used hashed address, where they are protected at rest again. It costs a fee, it links the old and new outputs for anyone watching, and it does nothing about the short-range attack that would target a transaction in flight, which no current address type prevents. For a large balance meant to sit for years, most people will find that worth doing. For a small spending balance, probably not.
4. Be careful what you pick as a “better” static address. Silent payments (BIP-352) solve the privacy side of static addresses well: one published code, a different on-chain output for every payment. But the BIP specifies that every output it creates is a Taproot output, so each one is exposed at rest from the moment it is funded. It fixes linkability, not quantum exposure.

None of these steps depends on any proposal being accepted. A future output type like BIP-360 would add a new place to put coins; it would do nothing for coins already sitting on a revealed key. Moving them, if you decide to, is something only the owner can do.

On the timeline

No computer today can run Shor's algorithm against a 256-bit elliptic curve key. The gap is measured in orders of magnitude of error-corrected qubits, and anyone giving you a year is guessing. What is not a guess is which of your coins have a public key on the chain. For reused addresses the answer is written in the transaction history, and it does not change by waiting.