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 answer is "nothing 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.

• 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.

Informational means what it sounds like. The draft states that it "introduces no consensus, policy, or peer-to-peer protocol 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 "seems 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.

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 vulnerability applied to one output: an attacker could work offline and spend "at a time of its choosing" 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 minutes between broadcast and confirmation. The draft stresses that this level describes an output that is "safe at rest", and notes the name has been misread, with EXPOSED_WHEN_SPENT under consideration as a clearer label.
• NOT_EXPOSED is a box that needs no elliptic-curve key at all. The draft is blunt that "no output type deployed at the time of writing has this property." 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 available data is insufficient to distinguish between 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

The motivation section opens with a confession. The author runs a tool that classifies mainnet addresses, and for its first month in production it labelled an address that had been spent from, and still held coins, as "exposed on spend". The draft says 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."

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 implementation "MUST NOT assign a lesser level to a reused, previously-spent script merely because the key was disclosed by a spend rather than by the scriptPubKey."

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 that splitting the two into different levels "invites the reading that reused addresses are safer than P2PK, which is false."

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.

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. The draft calls this "precisely the design goal of BIP 360": removing the key path is what P2MR is for. 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 labelled 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 every script leaf you can satisfy today is satisfied with an ordinary secp256k1 signature. Spending one 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 until BIP-360 activates, a witness version 2 output of that shape "is spendable by anyone under current consensus rules." 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 "may report EXPOSED_ON_SPEND for a key whose full public key has been on-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 the whole balance and send no change or new funds back to the same script.
• 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 a product: "Any never-used hash-committed script is 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 that "as of March 1, 2026, over 34% of all bitcoin have revealed a public key on-chain." This site's own supply page uses an estimate near a quarter. The draft says published estimates run "from about 25% to over 34%" and argues the spread "is not measurement noise." It 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. Two honest analysts can look at the same chain and get numbers nine points apart.

Is this a freeze or a new rule?

No. The pull request describes its scope as "observation only," and says it "does not score risk and does not propose freezing or forced migration." It lists BIP-361, the proposal to phase out legacy signatures, as complementary but independent: neither depends on the other being adopted. 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.