A Draft BIP Sorts Every Bitcoin Output Into 4 Quantum Exposure Classes. The Best One Available Is 'Exposed on Spend'

What Happened

A developer publishing as duncan0k opened pull request 2294 against the Bitcoin Improvement Proposals repository on September 18 with a draft titled 'Output Public Key Exposure Classification.' It is an informational document, not a consensus change, and it has no BIP number yet.

It assigns every existing Bitcoin output exactly 1 of 4 levels against an attacker holding a cryptographically relevant quantum computer: EXPOSED_AT_REST, EXPOSED_ON_SPEND, NOT_EXPOSED, and UNDETERMINED. The first 2 are the 'long exposure' and 'short exposure' attacks that BIP-360 defines, applied to a single output.

The abstract contains the sentence that matters: 'No deployed output type is NOT_EXPOSED.' A Python reference implementation with published test vectors sits alongside it, and the draft went through Delving Bitcoin and the bitcoin-dev mailing list in early September before reaching the repository.

On Wednesday, Mark Erhardt, the Bitcoin Core contributor known as Murch and 1 of the repository's BIP editors, posted the first editor review. He wrote that he is 'on the fence whether it is necessary to document this classification' but open to being convinced by reviewers who state their support, and he asked for a shorter, more technical text.

The author pushed version 0.6.0 Wednesday night: the prose went from about 4,700 words to about 3,000, the test vector outcomes did not change, and 1 rule was extended so that every output paying the same script now shares 1 exposure window. Nothing in it is activated, adopted, or numbered.

What it does is state, in rules a wallet can implement, which of your coins a quantum attacker could take without warning and which it could only race you for.

Holding your own keys lets you choose between exposed at rest and exposed on spend. The class that means safe is still empty, and no key you hold can fill it.

Four Classes, and Why Taproot Shares the Worst One With a Reused Address

The sorting starts from the script that locks the coin. If the script itself contains a public key, the output is EXPOSED_AT_REST: an attacker with the machine can derive the private key offline and spend at any time. That covers pay-to-public-key outputs from 2009, bare multisig, and every Taproot output, the bc1p addresses in use since November 2021.

The draft is blunt about Taproot: the 32-byte output key sits in the scriptPubKey, consensus never checks how it was built, and a provably unspendable internal key does not help, because 'an adversary who computes the discrete logarithm of Q can sign a key-path spend.' Hash-committed outputs, the 1, 3, and bc1q address families plus BIP-360's proposed bc1z outputs, are EXPOSED_ON_SPEND: nothing is on the chain until you spend, and then the key waits in the mempool for as long as confirmation takes.

UNDETERMINED is for scripts the software does not recognize. NOT_EXPOSED is defined and empty; it exists so that a future post-quantum output type has a name waiting for it.

2 rules do the real work. The first is the derived condition: if an earlier transaction has already published the key material needed to spend an output, the output is EXPOSED_AT_REST regardless of its type. Any address you have spent from and still hold coins on therefore sits in the same class as Satoshi's coins, and the draft refuses to soften that: separate levels 'would suggest that a reused address is safer than P2PK.'

The second is the fail-closed rule: where the data cannot distinguish 2 levels, the more exposed one is assigned, because 'under-reporting gives false assurance; over-reporting costs an unneeded migration.' The draft also names a blind spot that trips ordinary block explorers: pay-to-public-key outputs have no address, so an address-indexed tool can miss a key that has been on the chain since 2009.

Definitional slack of that kind, the draft argues, is why published estimates of exposed supply range from about 25% to over 34%. BIP-361 uses the 34% figure as of March 1; Project Eleven's tracker and Coinbase's quantum advisory board both put the total near 6.9 million BTC.

How to Sort Your Own Coins

You do not need the reference implementation; you need your addresses and your spend history. First, read the prefix. bc1p is exposed at rest today, whatever wallet made it. 1, 3, and bc1q are exposed on spend, provided the second check passes. Second, check whether you have ever spent from the address.

If you have and it still holds a balance, or you have sent funds back to it since, it is exposed at rest. A hardware wallet that generates a fresh address for each receive passes this check by default; a donation address or a reused exchange deposit address fails it. Third, check what left the chain.

The draft lists disclosures it cannot see: an extended public key handed to a portfolio tracker, an accountant, or a collaborative custody service reveals every key it can derive, including keys of outputs you have never spent, and so does signing with the same key on a fork or a sidechain.

Those coins are exposed at rest on any honest reading, and no explorer will say so.

Then act on the class. For anything exposed at rest, the draft's floor is MIGRATE: move the coins to a fresh hash-committed address and stop adding funds to the old one in the meantime. For anything exposed on spend, the floor is SWEEP_WHEN_SPENDING, and version 0.6.0 tightened it: when you do spend, spend every output paying that script in 1 transaction, send change to a new address, and never receive to that script again.

A multi-sig under P2WSH follows the same rule at the script level, because the day it is spent, every key in the quorum is public. For UNDETERMINED, treat it as migrate. None of this costs more than a transaction fee, and all of it can be done this week.

What This Means for You

The draft's most useful sentence is its most uncomfortable one. There is no class today that means safe. Self-custody, in the specific sense of holding your own private keys, lets you choose between the top 2 classes, and that choice is real: it is the difference between a coin an attacker can take offline whenever it likes and a coin it can only race you for during the minutes a spend waits in the mempool.

But key control ends there. It cannot move a coin to NOT_EXPOSED, because no output type that qualifies exists on Bitcoin, and BIP-360's P2MR, the proposal most often described as the quantum-resistant address, reaches only the second class, since a spend through a signing leaf publishes a key the way any P2WSH spend does.

The draft's own first 4 versions had P2MR in the empty class; version 0.5.0, the revision that followed Murch's earlier comments on Delving Bitcoin, corrected it. This publication has called BIP-360 quantum-resistant since April. 'Not exposed at rest' is the precise phrase, and the gap between the 2 is the point of the classification.

The second limit is that the chain is not the only place a key leaks. A holder who has never reused an address, who spends through a hardware wallet and sweeps every script clean, can still have handed an xpub to a tax tool or a portfolio app, and the newsletter-vendor and shipping-partner breaches in this archive show how reliably that kind of third-party data gets out.

The classification is honest that it cannot see this, and it forbids implementations from presenting a clean level as proof that nothing has been disclosed. Read that as a rule for yourself: an exposure class is a floor set by public data, and what you have shared privately can only raise it.

The skeptical case is straightforward, and the BIP editor made it first: a taxonomy does not change the threat, the largest curve key broken on real quantum hardware is still 15 bits, and a standard with 1 author, no number, and no named adopters can sit in review for months. That is fair, and it is also why the draft matters to a holder rather than to the network.

It makes no consensus claim and needs no soft fork. Its value is that 2 wallets looking at the same coin will give the same answer, and that the answer errs toward telling you to move. What it cannot give you is the class that means safe. That class stays empty until the network fills it, and the draft's candor about that is worth more than the reassurance a cleaner table would have offered.

What to Watch

The next checkpoint is whether other reviewers answer Murch's request for statements of support; without them the document may sit unnumbered, and with them a BIP number would make the 4 labels the vocabulary wallets and explorers share. Whether Bitcoin Core, Sparrow, or the major hardware wallet vendors fold the classification, or something like it, into their address-reuse warnings is the adoption signal that matters more than the number.

The naming dispute over EXPOSED_ON_SPEND versus EXPOSED_WHEN_SPENT is minor but will show whether the review is moving. Any post-quantum signature proposal that reaches the repository would be the first candidate for the empty class; until then, the table has 3 live rows and 1 placeholder.

Tracked entities this report names, with total coverage across the archive. Follow one into the Actor Network to see every report it appears in.

Other reports that name the same tracked actors — a different thread than “related,” which follows wording. These are linked by who appears in them.