Bitcoin's post-quantum discussions are exposing a problem larger than choosing a replacement signature algorithm. September exchanges between protocol researchers examined how people would move into new spending rules, how much data those rules would create, and who would bear the cost of checking them. Those questions remain useful guideposts for assessing proposals as of October 15.
Two discussions show the range of work: Pieter Wuille's output-type debate, including his September 11 response about adoption, and conduition's September 4 signature-aggregation proposal, discussed through September 16. They describe design choices and unresolved research, rather than an activated Bitcoin upgrade or an agreed migration schedule.
A standard is only one part of a system
Post-quantum cryptography is designed to withstand attacks by quantum computers as well as classical ones. NIST's program overview lists standardized digital-signature options and urges organizations to plan migration. Its standards timetable is a policy and transition framework; it does not establish when a machine capable of attacking Bitcoin will exist.
One available building block is SLH-DSA, a stateless, hash-based signature scheme derived from SPHINCS+. NIST published its FIPS 205 standard in August 2024. Having a defined algorithm helps implementers work from a shared specification. Bitcoin still needs to determine how any selected scheme would fit its transaction rules, resource limits and software ecosystem.
Our assessment is that these are separate milestones worth tracking. An algorithm can have a published standard while a proposed Bitcoin integration remains incomplete. Readers should ask what was actually standardized, implemented, tested or activated whenever a project makes a quantum-readiness claim.
What a new output would promise
The current BIP360 draft proposes Pay-to-Merkle-Root, or P2MR. It removes Taproot's key-path spending route and commits to a script tree. Its stated purpose includes reducing exposure to attacks against public keys visible for long periods, while providing a possible foundation for future post-quantum signature support.
The distinction between long and short exposure matters. Protecting a key before a payment is spent does not necessarily protect the interval in which spending reveals information. BIP360 expressly separates those threats and says fuller protection against short-exposure attacks may require post-quantum signatures. Its status is Draft. Treating P2MR alone as a complete, deployed answer would skip essential qualifications.
Wuille's September response focuses on actual adoption. He argues that users' established public-key-sharing practices complicate claims of categorical protection, and that an approach should be judged by whether people can use it correctly. He also questions whether bundling cross-input signature aggregation, a separate space-saving technique, would persuade slower-moving wallet providers to migrate. These are his arguments in an ongoing technical discussion, rather than a settled community position.
For readers evaluating progress, that suggests a practical question: what would a migration require of the least engaged user? A technically elegant option can still leave substantial exposure if people cannot recognize when to use it, or if applications adopt only part of the intended protection.
Smaller proofs introduce different costs
Conduition's September proposal considers aggregating many post-quantum signatures into one succinct proof for a block. The attraction is reducing the amount of signature data that nodes must carry and store. Creating such a proof requires substantial computation, however, and the proposal expects large mining pools may perform that work themselves.
The accompanying discussion raises implementation and denial-of-service concerns. A failure in proving software used by many miners could affect block production. On September 16, conduition also cautioned that an estimate derived from existing hash benchmarks was an extrapolation: the relevant SPHINCS-verification circuit had not yet been tested with Flock. Those limitations are part of the proposal's own discussion, and belong alongside its potential benefits.
The underlying Flock preprint, revised September 19, reports a proof-of-concept system for fast proving of repeated Boolean computations, including cryptographic hashes. Its abstract says the approach could, in principle, extend to complete hash-based signature verification. That is promising research evidence, with a narrower scope than a measured, production-ready Bitcoin block-processing system.
What meaningful progress would look like
For now, useful signals include a precise threat model, working implementations, reproducible end-to-end measurements and migration plans that ordinary applications can support. Reviewers also need to understand what happens when an assumption fails, whether that is a cryptographic weakness or an operational bug.
September's exchanges make these questions more concrete. They offer a way to judge future announcements without guessing a quantum-computer arrival date: examine the protection being promised, the users it reaches, and the costs it shifts elsewhere. A credible Bitcoin transition will need convincing answers across all three.