BIP362: Output Public Key Exposure Classification #2294

duncan0k commented at 10:37 AM on September 18, 2026: none

This is an Informational BIP that defines four exposure levels for existing Bitcoin outputs against an attacker holding a cryptographically relevant quantum computer: EXPOSED_AT_REST, EXPOSED_ON_SPEND, NOT_EXPOSED and UNDETERMINED. The first two are BIP 360's long exposure and short exposure vulnerabilities stated per output. The document adds the operational rules under BIP 360's per-type list: what counts as revealed, for which outputs, what to report when history is truncated, a fail-closed default, test vectors, and an informative appendix of per-level action keys that wallet developers asked for.

Scope: observation only. No consensus, policy or P2P change. It does not score risk and does not propose freezing or forced migration.

Discussion:

Delving Bitcoin: https://delvingbitcoin.org/t/standardizing-an-exposure-classification-for-existing-outputs-pre-bip/2866 (murch suggested submitting as Informational; wallet feedback led to Appendix A)
bitcoin-dev: https://gnusha.org/pi/bitcoindev/010001a06dd4cdd9-b8082042-8750-4e9a-917e-2053c919e4c4-000000@email.amazonses.com/ (conduition's review led to v0.3.0)

Reference implementation and 25 test vectors, CC0: https://github.com/duncan0k/pubkey-exposure-classification

Revision history since first posting: v0.2.0 tightened the derived condition; v0.3.0 separated attacker-spendability from holder-provability (conduition); v0.4.0 added Appendix A (GemWallet); v0.5.0 mapped the levels onto BIP 360's terms and corrected P2MR from NOT_EXPOSED to EXPOSED_ON_SPEND (murch's pointer to BIP 360 surfaced the error); v0.5.1 notes the pre-activation anyone-can-spend case for witness v2 outputs; v0.6.0 condensed the text and covered outputs that share a script (murch's review); v0.6.1 makes NOT_EXPOSED require a post-quantum signature on every spending path, so hybrid schemes count (murch).

Disclosure: I used an LLM to help draft the English. The classification, the rules, the vectors and the mistakes are mine, and I answer for all of it.

Add BIP draft: Output Public Key Exposure Classification f9c7b68bb4

jonatack added the label New BIP on Sep 18, 2026

in bip-output-pubkey-exposure-classification.md:145 in f9c7b68bb4

 140 | +vulnerability. BIP 360 notes that Bitcoin outputs are generally subject to it; that includes
 141 | +P2MR until a leaf can be satisfied without secp256k1 key material.
 142 | +
 143 | +Note that this level describes an output that is *safe at rest*: the holder still knows something
 144 | +the adversary does not. The name has been read as "already exposed" by at least one reviewer;
 145 | +`EXPOSED_WHEN_SPENT` is under consideration as a clearer label (see Rationale).

murchandamus commented at 7:49 PM on September 23, 2026:

The description of this level should cover address reuse more comprehensively. If a wallet tracks multiple UTXOs received to the same output script, the exposure window opens when a transaction spending any of the TXOs is broadcast, and closes when all UTXOs received to the output script have been spent.

Alternative naming ideas should appear in Rationale or Footnotes, not in the Specification section.

duncan0k commented at 1:39 AM on September 24, 2026:

Addressed in 2183bf5: a second paragraph under EXPOSED_ON_SPEND covers outputs that share a script, and the naming note is gone from the Specification (the discussion stays in Rationale).

murchandamus commented at 8:10 PM on September 23, 2026: member

I’m on the fence whether it is necessary to document this classification, but I’m open to be convinced by reviewers stating their support for publication of this document.

Either way, this document is needlessly wordy — it reads more like an essay than a technical proposal. Please use shorter sentences, cut unnecessary framing, prefer direct statements, and drop unnecessary narrative. Aim for a concise technical writing style assuming a technically competent audience.

murchandamus added the label PR Author action required on Sep 23, 2026

Condense text; cover shared-script exposure window in EXPOSED_ON_SPEND; drop naming note from Specification (v0.6.0) 2183bf543a

duncan0k commented at 1:39 AM on September 24, 2026: none

Thanks for the review. v0.6.0 is pushed (2183bf5):

Rewrote the text for length. The prose went from about 4,700 words to 3,000, the Motivation has no narrative left, and each Rationale entry is a few sentences.
EXPOSED_ON_SPEND now covers outputs that pay the same script, as you described: the window opens when a spend of any of them is broadcast and closes when the spend of the last one is confirmed. Once a confirmed spend has published the key, the rest are EXPOSED_AT_REST under the derived condition. The Appendix A floor for that level now says to spend every output on the script in one transaction.
Removed the naming note from the Specification; the discussion stays in Rationale.

While tightening the text I also cleaned up a few edge cases around spend paths that need no signature. The draft no longer claims that every P2MR leaf needs a secp256k1 signature, it notes that a depth-zero P2MR tree is spendable by anyone once its leaf is revealed, and the aggregate-count floor is only lowered once every spend of the script has been seen. The Changelog lists these. Test vector outcomes are unchanged.

duncan0k commented at 11:41 PM on September 30, 2026: none

@murchandamus v0.6.0 (2183bf5) went up on the 24th with the changes from your review. The text is down to about 3,000 words, EXPOSED_ON_SPEND now covers outputs that share a script, and the naming note is out of the Specification. Could you take another look when you get a chance? If anything else needs changing, let me know. If not, could the "PR Author action required" label be removed?

l0vvkey commented at 2:28 PM on October 8, 2026: none

I work in BD and support at Gem Wallet, not as a developer, so I can't review the technical details.

I suggested on Delving that each level should come with a simple recommended action, and I'm glad that was added. From a support point of view, if wallets start warning users about quantum risk, it would help if they all gave the same basic advice. Otherwise users get confused when two wallets say different things about the same coins. For that reason, I'd support publishing it.

duncan0k commented at 4:15 PM on October 9, 2026: none

cc @conduition, since you replied to the first post on the list. Your point about P2TR outputs without an internal key ended up in the holder-provability note. The draft has changed a fair bit since then and could use a few more eyes, if you feel like taking a look. No pressure either way.

duncan0k commented at 4:09 PM on October 19, 2026: none

@murchandamus @jonatack The changes from the Sep 23 review went in with 2183bf5 on Sep 24. If nothing else is needed from my side, could the PR Author action required label come off?

in bip-output-pubkey-exposure-classification.md:112 in 2183bf543a

 154 | -applies: nothing sits on the chain to attack at rest, and nothing appears in the mempool at spend
 155 | -time. This level is a property of the output *type*, established by its consensus rules. It MUST
 156 | -NOT be inferred for a hash-committed script from the absence of evidence about the script's
 157 | -contents.
 158 | +The consensus rules of the output's type do not require secp256k1 key material to spend it, so
 159 | +neither attack applies. This level is a property of the output type. It MUST NOT be inferred for a

murchandamus commented at 5:35 PM on October 19, 2026:

Instead of requiring that an output doesn’t rely on elliptic curve key material, it would be more accurate to require a post-quantum signature scheme. For example a hybrid scheme could rely on elliptic curve cryptography but still be PQ-safe.

duncan0k commented at 7:05 PM on October 19, 2026:

Good point. The old test would have ruled out exactly the hybrid case. c306a91 asks for a post-quantum signature on every spending path instead. I also had to say that this level wins over the at-rest conditions, since a hybrid output could carry an EC key in its scriptPubKey.

in bip-output-pubkey-exposure-classification.md:412 in 2183bf543a

 497 | +  and defined "disclosed" by the two `EXPOSED_AT_REST` conditions, so a revealed script or leaf
 498 | +  that requires no signature is not disclosure; the aggregate-count floor is now lowered only after
 499 | +  every spend of the script has been retrieved; dropped the claim that every satisfiable P2MR leaf
 500 | +  requires a secp256k1 signature; stated that a pre-activation witness version 2, 32-byte output
 501 | +  carries the P2MR level and is flagged separately; and noted that a P2MR output with a depth-zero
 502 | +  tree is spendable by anyone once its leaf script is revealed, which implementations SHOULD flag.

murchandamus commented at 5:49 PM on October 19, 2026:

The 0.6.0 Changelog entry could be more concise. It is much more verbose than the prior ones.

duncan0k commented at 7:06 PM on October 19, 2026:

Fair, that one read like a diff. Trimmed it to the size of the others in c306a91.

murchandamus commented at 5:54 PM on October 19, 2026: member

Sorry, I was out of the office. Thanks for the update, the new text reads much better.

murchandamus removed the label PR Author action required on Oct 19, 2026

Define NOT_EXPOSED by a post-quantum signature on every spending path; shorten the 0.6.0 changelog entry (v0.6.1) c306a911a4

Do not say that a spend through a script needing no signature publishes no key material (v0.6.1) 20cad1bb04

zeenix commented at 8:12 PM on October 19, 2026: none

@duncan0k Hi, I’ve posted a companion proposal on wallet transaction construction for EXPOSED_ON_SPEND outputs to bitcoin-dev: https://groups.google.com/g/bitcoindev/c/LcczFuBQjsE (I took the liberty of adding you to CC there, I hope you don't mind). If it ends up as a separate document, would you be open to a cross-reference from Appendix A?

duncan0k commented at 4:19 AM on October 20, 2026: none

@zeenix Sure. Once it has its own document and a stable link, I'm happy to point to it from Appendix A. The floor there is meant to stay minimal and yours covers the full construction rule, so keeping them separate sounds right to me.

cryptoquick commented at 6:37 PM on October 20, 2026: contributor

This is cool

We planned to do work like this before everything fell apart

Helpful messages to users in their wallets about the state of their exposure

I'm supportive of this work but I'm not sure how much heart I have anymore for it

duncan0k commented at 4:37 PM on November 2, 2026: none

@jonatack nice to see exposure classification come up on #2340. Is there anything else this one needs before it can get a number? Happy to do another pass if so.

jonatack commented at 5:26 PM on November 2, 2026: member

Assigned 362. Please update and add a README entry.

jonatack renamed this:
~~BIP Draft: Output Public Key Exposure Classification~~
BIP362: Output Public Key Exposure Classification
on Nov 2, 2026

BIP362: rename file, fill in preamble, add README entry fdcc9cbeb4

duncan0k commented at 4:39 AM on November 3, 2026: none

Thanks, I'll take that over another pass. Done in fdcc9cb: the file is bip-0362.md now and the README entry is in.

BIP362: update author email adfc6743e8