Bitcoin’s quantum question starts with signatures, not slogans

“Quantum computers will break Bitcoin” compresses several different questions into one sentence. Which cryptographic operation is being attacked? What information is available? How powerful must the machine be? What could the network change before such an attack becomes practical?

Separating those questions produces a more useful assessment than attaching a countdown to an unfamiliar qubit number. This article is a technical reference based on sources checked September 22, 2026, not a forecast of when a practical attack will exist.

Signatures authorize spending

Bitcoin uses cryptographic signatures to help enforce spending conditions. BIP 340 specifies Schnorr signatures over the secp256k1 elliptic curve and explains Bitcoin’s earlier use of ECDSA over the same curve.

The relevant security assumption concerns recovering a secret scalar from a public elliptic-curve point. With that secret, an attacker could potentially generate signatures that satisfy the affected spending condition.

Shor’s algorithm provides the foundational quantum approach to discrete logarithms and factoring. The algorithmic result does not supply a working machine, an attack budget or a date. Applying it to an actual signature system requires a sufficiently capable implementation of the required computation.

The important threat is not that a quantum computer simply “decrypts a Bitcoin address.” Addresses, public keys, private keys and signatures have different roles. Loose terminology makes the attack sound simpler than its technical prerequisites.

Hashing presents a different problem

A cryptographic hash can commit to data without displaying that data directly. Taproot’s specification, for example, uses hashes in its script-tree construction while also defining a public output key and signature-based spending paths.

Hash functions and elliptic-curve signatures do not share the same attack mechanism. Grover’s quantum search algorithm gives a quadratic improvement for an idealized unstructured search problem. That differs from the discrete-logarithm result associated with Shor’s algorithm.

A square-root reduction in search queries is substantial, but it is not a statement that a hash can be reversed instantly. Actual attack costs depend on the function, target, circuit and implementation. Collision finding, preimage finding and signature forgery are also different objectives.

Consequently, “Bitcoin uses 256-bit cryptography” is not a complete security assessment. The number needs an operation and a threat model attached to it.

What NIST standardized

NIST finalized three prominent post-quantum standards on August 13, 2024. They serve different purposes:

The official descriptions of FIPS 203, FIPS 204 and FIPS 205 establish that distinction. An encryption or key-establishment headline should not be read as a ready-made replacement for transaction signatures.

ML-DSA and SLH-DSA offer different constructions and tradeoffs. Standardization provides a concrete algorithm specification to evaluate. It does not select Bitcoin’s future consensus rules, update existing outputs or make every implementation correct.

At the September 22 review, the FIPS 204 page also carried a July 31, 2026 planning note about minor issues intended for a future revision. Even a finalized standard needs version and errata awareness when used in engineering.

Public-key exposure changes the attack window

An attack needs the relevant public information. If a vulnerable public key has been exposed for a long period, a hypothetical attacker may have a longer opportunity to work on it. If it becomes available only during a spending process, the timing problem is different.

Taproot outputs expose an output key under BIP 341. This observation is about that output construction; it does not show that a practical quantum attacker currently exists.

Consider two hypothetical capabilities. Machine A takes months to recover a targeted key. Machine B can do so during a brief transaction-confirmation window. Those are different threat scenarios, even if both exploit the same mathematical weakness.

Neither scenario supplies a probability that such hardware will arrive. They explain why research distinguishes long exposure from short exposure and why one mitigation need not solve both.

A proposal is not an activated defense

When checked on September 22, 2026, BIP 360 was labeled Draft, version 0.12.1, under the title Pay-to-Merkle-Root (P2MR).

The proposal removes Taproot’s key-path spending feature from a proposed new output type. Its stated objective includes resistance to long-exposure attacks. It explicitly does not introduce a post-quantum signature scheme or, by itself, solve short-exposure attacks.

That scope matters more than calling the proposal “quantum protection.” Readers should check the current document for changes; this is a dated description of a draft, not a claim of deployment.

An algorithm standard and a proposed output type answer different parts of the migration problem. Neither automatically changes the conditions controlling coins already held in existing outputs.

Migration is an engineering and coordination problem

A hypothetical migration plan would need to address signature verification rules, transaction sizes, wallet support, hardware compatibility and the process for moving existing holdings. It would also need clear treatment of users who cannot or do not migrate.

Those questions involve costs and choices beyond selecting an algorithm with a post-quantum label. A new signature method can affect verification resources and transaction construction. A wallet update alone cannot make the network accept spending rules it does not recognize.

A useful research update therefore names the proposal, version, implementation evidence and activation status. A useful hardware claim names the cryptographic task and resources demonstrated.

For ordinary readers, the disciplined position is to follow concrete milestones: specifications, tested implementations and agreed deployment changes. A claim about a future machine becomes meaningful when it states exactly which part of Bitcoin it could attack and under what conditions.