A draft BIP wants every wallet to describe the box the same way

Updated September 2026

The draft asks one question of each output: how much would someone with a large enough quantum computer still have to do to take the coins? If the public key is already on the chain, the attacker has nothing left to do but wait, and the output is exposed at rest. If the key only appears when you spend, the attacker would have to win a race against your own transaction, and the output is exposed on spend.

What was submitted, and when

The document is called "Output Public Key Exposure Classification". Its author, who posts as duncan0k, first put it up for review on Delving Bitcoin on September 3, 2026, then on the bitcoin-dev mailing list the next day. After five revisions it went to the BIP repository as pull request 2294, opened on September 18, 2026, at version 0.5.1. It is now at version 0.6.0.

• September 3, 2026: first posted as a pre-BIP on Delving Bitcoin.
• September 14, 2026: version 0.4.0 adds an appendix of suggested actions per level, after a wallet developer asked for one.
• September 18, 2026: version 0.5.x maps the levels onto the terms BIP-360 already uses, reclassifies P2MR, and is submitted as an Informational BIP.
• September 23, 2026: Murch reviews the pull request, asks for shorter, more direct text and a fuller treatment of address reuse, and is undecided about publication.
• September 24, 2026: version 0.6.0 condenses the text, by the author's count from about 4,700 words to 3,000, and gives outputs on the same script one shared exposure window.

Informational means what it sounds like. The draft states that it "introduces no consensus, policy or peer-to-peer change." Nobody's node behaves differently because of it. What it tries to change is the software that looks at the chain and tells people what it sees: wallets, block explorers, address checkers like the one on this site, and the tools a custodian might use to decide which coins to move first.

Whether it gets a number is not settled. Murch replied on Delving that the classification looked trivial and questioned the value of a BIP for it, then said the repository is the right venue if other people find it useful. The author agreed that neither core rule is a discovery and argued that the value is in the edge cases. That is where this page spends its time too.

On September 23, 2026, Murch reviewed the pull request itself. The review says Murch is undecided about whether the classification needs documenting and could be persuaded by reviewers who back publishing it, asks for much shorter and more direct text, and asks for a fuller treatment of address reuse. The author pushed version 0.6.0 on September 24. It is shorter, gives coins on the same script one shared exposure window, and changes the advice for the exposed-on-spend level to spending every coin on that script in one transaction. The levels themselves did not change, and the pull request is still open with no BIP number. The quotations on this page follow version 0.6.0 unless they say otherwise.

The four levels, in box terms

This site has always drawn one line: a closed box versus an open box. The draft draws the same line and adds two careful labels at the edges.

• EXPOSED_AT_REST is the open box. The public key, or everything needed to spend, is already published on the chain. The draft calls this BIP-360's long exposure applied to one output: an attacker could work offline and spend "at any time, with no warning to the owner."
• EXPOSED_ON_SPEND is the closed box. Only a hash is on the chain. The key appears when you spend, and the risk lives in the short time between broadcast and the spend being confirmed and buried. If several coins sit on the same script, they share one window: it opens as soon as a spend of any one of them is broadcast, and it stays open until the last of them has been spent and that spend is confirmed and buried. Once a spend has confirmed, the coins still on that script are exposed at rest. The draft's rationale stresses that this level describes an output that is "safe at rest", and notes the name has been misread, with EXPOSED_WHEN_SPENT as "the leading alternative."
• NOT_EXPOSED is a box that needs no elliptic-curve key at all. The draft is blunt: "No deployed output type qualifies." The level exists so a future post-quantum output type has somewhere to go.
• UNDETERMINED means the software cannot tell. The rule is that it must say so, rather than call an output safe.

Holding it all together is what the draft calls the fail-closed rule: "where the available data cannot distinguish two levels, the level indicating greater disclosure MUST be assigned." The reasoning is stated plainly. Telling someone an exposed output is fine is a worse mistake than suggesting a move that turns out to be unnecessary.

Which address types land where

For an output whose key has never been published anywhere else, the draft assigns a level from the output type alone:

If you have read which address types keep the box closed, nothing in the first seven rows is a surprise. The old P2PK outputs were never closed. Hash-based types stay closed until they spend. Taproot is open on arrival. What the draft adds is a rule for the row that is not in any table: the address you have already spent from.

The case tools got wrong: a spent-from address that still holds coins

Earlier versions of the draft opened with a confession. The author runs a tool that classifies mainnet addresses, and for its first month in production it labeled an address that had been spent from, and still held coins, as "exposed on spend". Those versions said that label was wrong: "The public key had been on the chain since the first spend, and an attacker does not need to wait for the next one." Version 0.6.0 drops the story and keeps the point in one line: "Its key is on the chain, but some tools report it as exposed only when next spent."

So the draft has a second way to reach the open-box level, which it calls the derived condition. An output is exposed at rest if everything needed to spend it was published by an earlier transaction, typically because the same key or script was used before and spent from. It then closes the loophole in capitals: an output that meets the derived condition "MUST NOT be assigned a lower level than one that meets the structural condition."

That is the same point this site makes in address reuse opens the box. Receiving more coins to a string you have already spent from does not seal anything again. To an attacker it looks the same as P2PK. The draft even warns: "Separate levels would suggest that a reused address is safer than P2PK."

The same logic covers change sent back to the address you spent from, and it covers multisig: for an m-of-n script, the draft counts an output as disclosed once any m of the n keys have been published, along with the script itself.

Why Taproot counts as exposed at rest

This is the row that drew the most argument. A Taproot output commits to a tweaked key, written Q, in the clear. Many Taproot wallets build Q from an internal key plus a script tree, and some use a provably unspendable internal key so that only the scripts can be used. Some readers took that to mean such outputs are safe.

The draft disagrees, for a simple reason. Whoever solves for the private key behind Q can spend through the key path directly. Consensus "does not check how Q was constructed", so a hidden internal key does not stop that. Removing that key path is what P2MR, from BIP-360, is for: in the draft's words, "P2MR has no key path." That matches what this site says in Taproot opens the box on arrival.

The draft does record a real nuance, raised in review on the mailing list. A Taproot owner still holds a secret an attacker would not learn from Q, namely the internal key and the script tree. That could matter for a future rescue mechanism that asks owners to prove what they know. But it does not change what an attacker can do today, so the draft lets wallets report it as a separate note and forbids letting it lower the level.

Why P2MR is not labeled safe

For four revisions the draft put P2MR, the new output type in BIP-360, at NOT_EXPOSED. Version 0.5.0 moved it to exposed on spend and called the earlier choice "an error."

The reasoning follows BIP-360 itself, which says "P2MR does not, by itself, protect against short exposure quantum attacks." A P2MR output keeps no key on the chain, so it is closed at rest. But nobody can see the leaves of an unspent tree, and one of them may require an ordinary secp256k1 signature, so the draft will not assume a leaf that needs none. Spending through such a leaf publishes that key in the mempool, which is the same race a P2WSH spend runs. Until leaves can use a post-quantum signature, P2MR is a very good closed box, not a box with no key.

There is one more line worth knowing. P2MR is not active. The draft notes that before BIP-360 activates, a witness version 2, 32-byte output "can be spent without key material." Version 0.6.0 adds a second case: after activation, a P2MR output whose tree has depth zero can be spent by anyone once its leaf script has been revealed. That is not a quantum problem. It is the absence of a lock. Nobody should send coins to a bc1z address today, whatever a tool says about it.

What the chain cannot see

The levels describe only what the block chain shows. The draft lists ways a key can leak without leaving evidence on Bitcoin's chain, and says an EXPOSED_ON_SPEND label must never be read as a promise that none of them happened:

• An xpub handed to a service, which discloses every child key derivable from it, including keys for outputs never spent.
• Spending the same coins on a fork that shares Bitcoin's history, which publishes the key on that other chain.
• Reusing the same key on a sidechain, a bridge, or another protocol.
• Anyone who holds the key publishing it or losing it.

There is also a practical blind spot. Many explorers index history by address, and P2PK outputs have no address, so they often do not show up in the history of the matching 1-address. The draft warns that a tool relying on such an index can "report EXPOSED_ON_SPEND for a key that has been on the chain since 2009," and asks tools to document the limit if they cannot work around it.

What each level asks you to do

A wallet developer asked on Delving for advice that two wallets would word the same way, and version 0.4.0 added it as an informative appendix. Each level gets one action key and one minimum piece of advice. Wallets can say more but should not contradict it.

• Exposed at rest: MIGRATE. Move the funds to an output type that is not exposed at rest once one you trust is available. Until then, do not add funds to it.
• Exposed on spend: SWEEP_WHEN_SPENDING. Nothing to do while it sits. When you spend, spend every coin on that script in one transaction and send no change or new funds back to it.
• Not exposed: NONE. Nothing to do.
• Undetermined: TREAT_AS_MIGRATE. Treat it as exposed at rest until the software can tell.

Notice what "an output type that is not exposed at rest" means today. The draft says it names a property, not an output type: "Hash-committed outputs with no prior disclosure, including P2MR (BIP 360) once available, are not exposed at rest." In other words, a fresh bc1q address you have never spent from already qualifies. That is the same hygiene step described in how to move coins to a still-closed address, and it is not urgent. No quantum computer that exists can derive a secp256k1 key from a published public key.

You can check where an address sits on the closed and open line with Schrödinger's Wallet. It already treats a spent-from address as open and Taproot as open on arrival, which lines up with the draft's first two levels.

Why the exposed-supply numbers disagree

You may have seen very different figures for how much bitcoin sits in open boxes. BIP-361 states: "As of March 1, 2026, over 34% of all bitcoin have revealed a public key on-chain." This site's own supply page compares the published counts. The draft says published estimates range "from about 25% to over 34%," and it puts the spread down to definitions rather than measurement. The spread comes from choices that are rarely stated: whether reused, spent-from addresses count now or only at their next spend, whether Taproot counts, what to do with a P2SH script never revealed, and whether keys leaked through xpubs or forks are included.

That is the most useful thing to take from the draft even if it never gets a number. When you read an exposure figure, ask which of those choices it made. Careful counts of the same chain at nearly the same time still differ: in May 2026, Glassnode counted about 30 percent of issued supply as exposed and Project Eleven about 34.5 percent.

Is this a freeze or a new rule?

No. The pull request limits itself to describing outputs: it assigns no risk scores and proposes neither a freeze nor a forced migration. It treats BIP-361, the proposal to phase out legacy signatures, as independent. In the draft's words, "Neither depends on the other." If you want the harder debate, start with what BIP-360 actually proposes and the SHRINCS draft for hash-based signatures, which is the kind of scheme a truly not-exposed output would need.

What the draft does is small and useful. It turns the box into a shared vocabulary, with a rule that tools must err toward the open box when they cannot see inside. For someone holding keys, the practical reading is the one this site has given all along: check whether your box is open, avoid reusing addresses you have spent from, and remember that Taproot is open from the moment coins arrive.