Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.
A draft addressing a specific exposure, not a timeline
BIP360, titled 'Pay-to-Merkle-Root' and created 18 December 2024 by Hunter Beast, Ethan Heilman and Isabel Foxen Duke, carries draft status, meaning, as with any draft BIP, that it is a proposal under discussion rather than a specification any node currently enforces. It responds to a specific development in cryptography: in August 2024, the United States' National Institute of Standards and Technology approved three finalised standards, FIPS 203, 204 and 205, for cryptography intended to resist attack by a sufficiently capable quantum computer, a milestone that motivates BIP360's premise, not an event that happened to Bitcoin itself.
Which coins the proposal treats as exposed
The document's premise turns on a detail of how Bitcoin addresses work, described in the developer guide: a public key is not published on-chain when coins are received, only its hash; the full key becomes visible only once those coins are spent. BIP360 defines a new output type, using addresses with a 'bc1z' prefix, that requires spending through a revealed script condition rather than through the single tweaked key that ordinary taproot key-path spending allows, on the reasoning that an exposed public key is the specific piece of data a quantum attack of the kind FIPS 203 to 205 anticipates would need. Coins sitting in addresses whose public key has never been revealed, by this reasoning, are not the exposed category the proposal targets; coins in an address that has already been spent from, leaving its key visible in the historical record permanently, are.
The boundary: this is a governance problem before it is a deployment
BIP360's draft status means none of its address format, migration path, or timeline is settled; the document describes migration from existing taproot script trees as requiring 'minimal changes' but does not specify a deadline, an activation mechanism, or what happens to funds in exposed addresses whose holders never move them. No sufficiently capable quantum computer is documented to exist, and neither the FIPS approval nor this BIP's draft text claims otherwise; both are preparatory. The harder problem is coordination: any eventual migration requires wallets, exchanges and individual holders to act, and a coin whose owner has lost access, or never returns to move it, cannot be migrated by anyone else regardless of how sound the replacement cryptography is.
Questions to carry forward
- What proportion of circulating bitcoin sits in addresses that have never revealed a public key, versus addresses that have, and where is that figure reliably measured?
- If BIP360 or a successor were finalised, what mechanism would set a deadline for migration, and what would it mean for funds left in unmigrated addresses?
- Does describing this as a live risk overstate the current state of quantum computing capability relative to what FIPS 203 to 205 and this draft actually claim?
The two dated facts, FIPS approval in August 2024 and a draft BIP in December 2024, are directly documented. Everything past them, including whether this draft becomes the adopted path, is proposal and governance work still to be done, not a settled record.
Sources & reading trail
Defines the draft P2MR output type, its rationale, and the migration path from taproot script trees.
Source published: 18 December 2024 · Retrieved: 16 September 2026
NIST announcement confirming approval of FIPS 203, 204 and 205 for post-quantum cryptography.
Source published: 13 August 2024 · Retrieved: 16 September 2026
Living developer guide describing when a public key becomes visible on-chain versus remaining hidden as a hash.
Source published: Not established · Retrieved: 16 September 2026
Historical sources establish the record; the questions and interpretation are Block Due Diligence’s editorial analysis. This retrospective draft does not imply the site published on the event date.