What Matters
Bitcoin quantum exposure depends on the output and whether a usable public key is already visible. Unspent Taproot outputs expose an output public key; they are not simply hidden behind a hash. This revised ledger separates exposure from attack capability, proposal status and migration evidence. It withdraws the old risk score and unsupported current supply total.
A public-key exposure ledger can answer a useful, bounded question: which unspent outputs have an authorisation path whose public-key material is already known? It cannot determine when an attacker will acquire the required computing capability. It also cannot establish that a dormant owner has lost a key.
Those boundaries are essential. A ledger statistic can be precise about script types and still be incomplete about off-chain key disclosure. A cryptographic proposal can be promising without being deployed. A migration deadline can be prudent without forecasting the arrival of a machine capable of breaking a particular signature.
The central correction: Taproot publishes an output key
BIP-341 specifies a 32-byte Taproot witness program representing the output public key. It is visible when the output is created, before a spend. The hidden script tree does not change that fact. Our previous statement that a never-spent Taproot output exposes only a hash was wrong. [1]
This is not a recommendation to make an unplanned transaction. Moving funds has operational consequences, and a recipient format has to be supported correctly by the wallet and network. It is a correction to the classification of exposure. Describing an output as “unused” is insufficient to determine which public information exists.
Claim versus the protocol record
| Claim | Evidence-based correction | What remains unknown |
|---|---|---|
| Every unused modern address hides its public key. | Taproot’s output key is in its witness program. P2PKH uses a public-key hash; these are different constructions. [1] [2] | Whether additional relevant keys or scripts have been disclosed elsewhere. |
| BIP-360 already adds post-quantum signatures. | The reviewed Draft proposes Pay-to-Merkle-Root, removes the key-path spend and explicitly does not itself introduce a post-quantum signature scheme. [3] | Future consensus, deployment and any separate signature proposal. |
| NIST’s migration date predicts Q-Day. | NIST’s transition documents organise algorithm migration. They are not a Bitcoin attack-date forecast. [4] | When or whether a relevant attacker capability will emerge. |
| Dormant means lost. | Inactivity is observable; the owner’s possession of signing material is a separate fact. | Recoverability without direct evidence from the controller. |
Classify outputs before adding balances
The Bitcoin developer guide describes value as unspent transaction outputs, each identified by the transaction and output index. That provides the accounting unit for a reproducible inventory. An address count is not a BTC balance, and an address label is not an ownership proof. [2]
| Observed construction | What to record | Classification caution |
|---|---|---|
| Public key directly in a locking script | The public key and the actual spending condition. | For multisignature conditions, record threshold and each relevant key; do not reduce the script to an address label. |
| P2PKH | The hash and whether a matching public key has been revealed. | Fresh output creation does not prove that the key was never disclosed. |
| P2WPKH | The witness-program hash and evidence of matching key disclosure. | The spending witness contains a signature and public key under BIP-141. [5] |
| P2SH or P2WSH | Whether the script is known and which spending paths it permits. | A script hash is not enough to infer every underlying key or alternative path. |
| P2TR | The visible output public key and any separately known script information. | Do not classify it as key-hidden just because it has never been spent. [1] |
| Unrecognised or insufficiently examined script | Raw classification reason and unresolved questions. | Use “unclassified,” not a default safe category. |
A correct sum counts each in-scope unspent output once. If the same output qualifies under multiple exposure rules, it must not be added repeatedly. A separate table can describe overlapping reasons, but those reasons cannot be summed as independent balances. Similarly, a historical output already spent at the selected block does not belong in the current UTXO total.
DN Bitcoin Exposure Evidence Ledger
The revised instrument is a reproducible record design. It does not display a live supply number because we have not executed and published the required current extraction. It gives analysts a concrete specification for producing one without silently mixing balances, heuristics and forecasts.
| Record field | Required value | Why it is necessary |
|---|---|---|
| Snapshot | Network, block height and block hash. | Fixes the state being counted and allows a reorganisation to be detected. |
| Output identity | Transaction ID plus output index; value in integer satoshis. | Prevents duplicate counting and floating-point BTC summation errors. |
| Script classification | Exact parser version and classification result. | Makes the rule reproducible rather than dependent on a marketing name. |
| Exposure evidence | Direct output key, prior on-chain disclosure, documented off-chain disclosure, or unknown. | Separates what the chain proves from other evidence. |
| Spending-path analysis | Known authorisation paths, thresholds and unresolved branches. | A single key observation may not describe every spending condition. |
| Coverage | Processed UTXOs, failures, excluded classes and unclassified value. | Shows what the claimed total leaves out. |
Illustrative accounting example: suppose an analyst has three distinct outputs worth 2, 3 and 5 BTC. The first two satisfy one exposure rule, and the second also satisfies another. The union is 5 BTC, not 8 BTC. These are invented arithmetic inputs, not a sample of the Bitcoin ledger. The example explains why a deduplicated output set matters more than a large-looking sum of categories.
The minimum publication package should contain the extraction code or a reproducible specification, the fixed snapshot, mutually exclusive totals, overlap handling and the unresolved balance. A separate sensitivity analysis can add an explicit off-chain-disclosure assumption. It must not quietly relabel that assumption as an observed chain fact.
Long exposure and short exposure ask different questions
The BIP-360 authors distinguish a key visible for an extended period from one revealed during an unconfirmed spend. Their proposal addresses the former through a different output construction; protection against the latter requires additional work such as post-quantum signatures. [3]
There is no universal ten-minute theft window. Transaction propagation, fee selection, inclusion, competing transactions and the attacker’s computation all affect a scenario. A confirmation target is not a measurement of the attacker’s available time. A meaningful simulation would have to specify these assumptions rather than applying one date and one score to every output.
Exposure is therefore a condition in a threat model, not the probability of successful theft. The earlier gauge multiplied assumed dates, arbitrary readiness levels and supply estimates into a single score. That presentation created apparent precision without calibration against an observed outcome. We have removed it instead of treating a revised weight as new evidence.
Track migration maturity with named milestones
A useful readiness ledger has distinct rows for a paper, a specification, reviewed implementation, interoperability testing, activation mechanism, production activation and user migration. A project can complete one without completing the next. Recording a percentage hides which dependency remains unresolved.
The current BIP-360 document is Draft, version 0.12.1, in the reviewed repository. That status and its explicit limitations are the relevant observations here. They do not establish Bitcoin consensus, an activation date or availability in a particular production wallet. [3]
NIST published the final IR 8547 on 27 October 2026. It identifies vulnerable algorithms and migration to post-quantum standards. NIST’s accompanying explanation describes federal migration targets, including 2035 as the broader target and earlier deadlines for specified sensitive systems. These are transition requirements within their stated scope, not deadlines imposed on Bitcoin holders. [4] [6]
How to evaluate a quantum headline
Ask what has actually changed: a hardware experiment, a resource estimate, an error-correction result, an attack demonstration or a protocol deployment. These are not interchangeable. A physical-qubit count is not a complete attack specification, and a laboratory milestone does not supply an end-to-end runtime against Bitcoin’s curve.
NIST’s public explanation says the arrival of a cryptographically relevant quantum computer is unknown and expert estimates vary widely. It supports preparing for migration, not presenting a narrow “consensus Q-Day” as settled fact. [7]
For an implementation claim, request the exact algorithm, parameters, supported transaction path and evidence that the old vulnerable authorisation route is retired. A wallet can add a post-quantum component while retaining a classical recovery or owner path. The DN wallet authority register treats those paths separately. The signature byte-budget tool models encoding costs, not cryptographic composition or chain readiness.
Methodology and limits
This update compares primary specifications and standards and supplies an original inventory method. It does not publish a chain measurement, lost-coin estimate or market-price forecast. There is no current DN “exposed BTC” total in this revision. We also separate signing authority from confidentiality: public transaction data is already public, while encrypted records have a different harvest-now/decrypt-later question.
Refresh this page when a referenced proposal changes scope or status, an activation is established, a reproducible UTXO study is completed, or credible research changes the stated attack assumptions. A headline or token price movement alone is not a technical update trigger.
Frequently asked questions
How much Bitcoin is exposed?
A current total requires the dated extraction and classification described above. This revision does not endorse the old 4–6.3 million BTC range as a current measured fact.
Is an unused Taproot output key-hidden?
No. Its output public key is visible. Hidden scripts and an unspent balance do not change that output-key property.
Does BIP-360 solve every quantum attack?
No. Its stated scope is limited, and the reviewed document remains Draft. Its existence does not establish post-quantum signature deployment.
Are inactive early coins provably lost?
No. Inactivity alone does not establish ownership, possession of the key or inability to migrate.
Should a forecast year decide a transfer?
This article supplies no personalised transfer or investment instruction. Decisions need the actual wallet and protocol capabilities, operational risk and a verified migration path.
Corrections and change log
12 November 2026: corrected Taproot public-key visibility; withdrew unsupported current supply totals, assumed lost-key conclusions, a narrow consensus timeline and arbitrary risk scoring; corrected BIP-360’s scope; added NIST’s final transition report and a reproducible exposure ledger. Canonical URL and media remain. Send technical corrections with a specification version or reproducible extraction through the DN contact page.
Machine-readable review record
The record below is a bounded illustrative example. It is not a wallet scan, current-chain dataset or assessment of a deployed service. The schema identifier is an identifier, not a promised API endpoint. Downloads are local snapshots; no schedule or automatic refresh is active.
Primary sources
- BIP-341 — Taproot output public key is visible in its 32-byte witness program.
- Bitcoin transaction developer guide — UTXO identities/value and P2PKH public-key hash construction.
- BIP-360 Draft v0.12.1 — Draft P2MR output proposal; long-exposure scope, no new post-quantum signature scheme itself.
- NIST IR 8547 final — 27 October 2026 final transition report, not a Bitcoin Q-Day forecast.
- BIP-141 — P2WPKH witness public key/signature and distinct witness-script constructions.
- NIST transition announcement — Federal migration targets and scope; separates standards transition from attacker capability.
- NIST PQC explanation — Unknown CRQC arrival and broad expert uncertainty; preparation despite uncertainty.
