BIP 360 is a draft, not an activation vote

A public key left in the open is a letter on the table. A public key still hashed is a letter in a sealed envelope. BIP 360 is a proposal to give users a new envelope. It does not decide when, or whether, the table has to be cleared, and it does not claim that a cryptographically relevant quantum computer is in the next room.

BIP 360, "Pay-to-Merkle-Root (P2MR)," is in the Bitcoin Improvement Proposals archive as a draft consensus soft-fork specification. Status on the document is "Draft." The design is a new output type with nearly the same script-tree machinery as Pay-to-Taproot, except the quantum-vulnerable key-path spend is removed. Addresses would start with bc1z. The authors describe long-exposure attacks on keys that sit on the blockchain for a long time, and short-exposure attacks on keys revealed in the mempool while a transaction waits. P2MR is aimed at the first class. "This BIP does not take a position on any specific quantum computing timeline," they write, "but rather proposes a flexible and unobtrusive option for users that wish to mitigate this risk according to their own estimate of the timeline." Lost or inactive coins, freezes, and emergency recovery sit outside the document's scope.

That is the decision. The story is a concrete design entering public review, not proof that activation is near, and not a date on which Bitcoin breaks. NIST continues to standardize post-quantum signatures and to publish migration guidance, including changes when proposed algorithms fail public scrutiny. Federal planning timelines for other systems are not a Bitcoin activation schedule. They are a reminder that new cryptography needs years of review. The BIP repository's own rule is the one that belongs in every headline: publication is an editorial milestone, not evidence of community consensus, deployment, or adoption. Users with exposed public keys, including reused addresses and Taproot outputs that reveal a key, face a different threat profile from users whose keys remain hidden. Wallet makers and exchanges would need to support new addresses and migration flows. Node operators and the wider economic network decide whether a consensus change is accepted. Protocol rule, operator software, user migration, and any later legal or custodial wrapper around old coins are four different problems. Premature alarm can cause harmful transfers, scams, or rushed standards choices before the technical and governance work is ready. Wallet migration plans are incomplete. No shared policy exists for old vulnerable outputs. Performance, address size, interoperability, and activation design require more testing. NIST's candidate process is the object lesson in why. The status ledger should distinguish proposal publication, technical review, implementation, wallet support, activation discussion, and adoption. Inferring a quantum date from a company announcement is a category error. Presenting protective transfers as advice is another. The envelope is on the table for comment. The network has not voted to use it.