Coin Brief ENDE

A draft BIP would standardise which Bitcoin outputs expose their keys

A draft Bitcoin Improvement Proposal now open as pull request #2294 in the BIPs repository sets out to answer a question that quantum-resistance proposals take for granted: which existing outputs have their public keys exposed? Its author, posting as duncan0k, first raised it on Delving Bitcoin on 3 September and published version 0.6.0 on 26 September after review.

The starting point is a discrepancy. Published estimates of the share of bitcoin supply whose keys are exposed range from about 25% to over 34%. After tracing the sources, the author concluded that the spread is mostly definitional: tools disagree on whether Taproot outputs count as exposed at rest, whether a spent-from address that still holds a balance differs from pay-to-public-key, and how to treat a P2SH output whose script was never revealed. BIP 360, which defines an output type whose key stays off-chain until a script-path spend, and BIP 361, which proposes phasing out legacy signature verification, both assume an agreed answer.

The draft defines four levels - EXPOSED_AT_REST, EXPOSED_ON_SPEND, NOT_EXPOSED and UNDETERMINED - with an assignment table per output type and a fail-closed rule: where the data cannot tell two levels apart, the more exposed one applies. Two consequences are flagged as likely to be contentious. A reused, spent-from P2PKH output that still holds a balance is treated like P2PK, because to an attacker they are the same. And P2TR is exposed at rest regardless of how its internal key was built, since consensus never checks that. An appendix pairs each level with a recommended wallet action; in version 0.6.0 outputs paying the same script share one exposure window, and the advice is to spend all of them in one transaction.

A draft BIP would standardise which Bitcoin outputs expose their keys
A draft BIP would standardise which Bitcoin outputs expose their keys — Coin Brief

What it means

Any migration away from vulnerable signatures will involve software deciding, output by output, what is at risk - and if wallets, explorers and researchers disagree, the numbers attached to that decision will disagree too. A shared, deterministic classification with test vectors is the kind of plumbing that makes later debates about substance rather than definitions.

Whether it becomes a BIP is open. Reviewing the pull request, BIP editor Murch wrote that he is "on the fence" about whether the classification needs documenting, and is open to being convinced by reviewers who support publication.

Written by Victoria Shinder.