Can Quantum Computers Break Bitcoin? What Is Actually at Risk
Quantum computers cannot break Bitcoin today. No publicly demonstrated machine can recover a Bitcoin private key from its public key, and the engineering gap to a cryptographically relevant quantum computer remains large.
The long-term threat is nevertheless real. A sufficiently capable, fault-tolerant machine running Shor's algorithm could break the elliptic-curve signatures used to authorize spending. Exposure would depend on whether a public key is visible and how quickly the attack runs.
This is not the same as instantly breaking SHA-256, taking over mining or changing Bitcoin's supply limit. Signature theft is the central risk, and migration is the practical challenge.
As of September 23, 2026, Bitcoin developers are discussing concrete output types, signature schemes and rescue mechanisms. None of them is activated on mainnet, and a published BIP is not evidence of community approval or imminent deployment.
Quick answer
The threat is to spending signatures, not Bitcoin's rules
A future cryptographically relevant quantum computer could derive private keys from exposed secp256k1 public keys. Coins with long-visible keys would be the earliest targets; fresh hash-hidden outputs would mainly face risk while being spent. Bitcoin can add post-quantum authorization through a consensus upgrade, but the leading 2026 proposals are still drafts or design discussions.
- No known quantum computer can steal Bitcoin today, and no credible date for that capability exists.
- Shor's algorithm threatens ECDSA and Schnorr signatures; known Grover-based mining attacks are far less practical.
- BIP360, P2TRv2, SHRINCS and BIP361 solve different parts of migration, and none is a complete deployed defense.
What a quantum computer could actually break
Bitcoin uses ECDSA for older outputs and BIP340 Schnorr signatures for Taproot. Both depend on the elliptic-curve discrete logarithm problem on secp256k1. Shor's algorithm could solve it on a large, error-corrected quantum computer, deriving a private key from a known public key. See the BIP340 specification and a 2026 peer-reviewed resource analysis.
An attacker could then forge a spending signature. That would not reveal a seed phrase from an address hash, alter consensus rules or create more bitcoin.
01 · At rest
Known public keys are the first target
A slower future machine could work on P2PK, P2TR, reused or otherwise disclosed public keys for as long as the associated coins remain unspent.
02 · On spend
Fresh keys create a shorter race
Hash-hidden outputs reveal authorization data when spent. Stealing them requires key recovery fast enough to replace or reorganize the legitimate transaction.
03 · Migration
Coordination is the binding constraint
A usable defense needs signatures, consensus rules, fee accounting, wallet support, hardware signers, exchange integration and a policy for coins that never migrate.
Why signatures matter more than mining
Discussions often combine Shor's and Grover's algorithms. Shor's algorithm provides the dangerous break of elliptic-curve signatures. Grover's algorithm gives a quadratic theoretical speedup for searching a hash function such as SHA-256, but it does not turn a 256-bit hash into an easy problem.
The 2026 PRX analysis finds Grover-based mining impractical under known architectures. Error correction absorbs much of the advantage, quantum search parallelizes poorly, and classical miners already hash at enormous scale. Difficulty would also adjust to durable changes. Read the full Bitcoin analysis.
An attacker would not need to outmine the network to steal an exposed output. Recovering its signing key is the more direct threat.
Which bitcoin would be exposed first
The first category is long-exposed public keys. P2PK outputs place a public key directly onchain. Taproot P2TR outputs also commit an x-only public key in the output. Address reuse can expose the key protecting a remaining P2PKH or P2WPKH balance after an earlier spend, and sharing an xpub or descriptor may expose many derived public keys offchain.
Fresh P2PKH, P2WPKH, P2SH and P2WSH outputs hide a key or script behind a hash until spending. That reduces at-rest exposure if nothing was reused or disclosed. The spend still creates a shorter attack window in the mempool or during a reorganization.
Definitions matter. The PRX paper identifies over 1.7 million BTC in directly exposed P2PK outputs. Draft BIP361 uses a broader measure and says more than 34% of bitcoin had revealed a public key by March 1, 2026. The figures are not interchangeable.
There is no single honest qubit number
Logical qubits run an error-corrected algorithm; physical qubits are the noisy hardware used to construct them. Conversion depends on architecture, error rate, clock speed, error correction and runtime.
The peer-reviewed Google-led work estimates 1,200 to 1,450 logical qubits and 70 to 90 million Toffoli gates. Under its superconducting assumptions, an attack could run in minutes with fewer than 500,000 physical qubits. A July preprint reduces logical width to 835 qubits. A September preprint instead models 19,397 physical trapped-ion qubits and 25.7 days on an unbuilt specialized architecture.
These are improving models, not existing hardware. NIST says major hurdles remain and expert timelines range from a few years to a few decades.
P2MR and P2TRv2 take different migration paths
Draft BIP360 Pay-to-Merkle-Root, or P2MR, proposes a SegWit version 2 output beginning with bc1z. It removes Taproot's key path and commits to a script-tree root, hiding elliptic-curve keys while retaining a future signature-upgrade path.
P2MR does not add a post-quantum signature. An elliptic-curve leaf can become vulnerable during spending, and reuse can undo the benefit. Its witness is larger than a Taproot key spend but smaller than an equivalent Taproot script spend.
P2TRv2 is a concept, not an assigned BIP. It would resemble Taproot, add post-quantum-capable leaves and later disable elliptic-curve spending. Familiar fees and workflows may aid adoption, but the output point remains exposed until disabling. Pieter Wuille's comparison treats P2TRv2 and P2MR as complementary options.
SHRINCS is compact for PQC, but still large
The SHRINCS draft combines a compact stateful FXMSS path with a stateless SLH-DSA fallback. It lists a 48-byte public key, stateful signatures of 548 to 4,619 bytes and a 5,777-byte stateless signature.
Reusing a state counter can enable forgery. If state is uncertain, the wallet must use the larger fallback. The draft defines a signature only; opcodes, output types, fees and activation need separate work.
NIST finalized lattice-based ML-DSA in FIPS 204 and hash-based SLH-DSA in FIPS 205. SHRINCS borrows FIPS 205 machinery but uses a nonstandard parameter set, and its draft says a security proof remains TODO. It should not be described as a NIST-approved Bitcoin signature.
Migration and rescue are governance problems
BIP361 depends on a future post-quantum signature BIP. Phase A would restrict new payments to vulnerable output types about 160,000 blocks, or three years, after activation. Phase B would tighten legacy spending two years later and add rescue rules.
This raises questions about dormant owners, lost keys and coins lacking another secret. The BIPs repository stresses that publication does not signal consensus or adoption.
DropKick is a commit-and-reveal rescue sketch. A holder commits to a post-quantum key and earlier secret knowledge, then reveals both after a delay. It needs PQ signatures first, cannot cover P2PK coins and adds miner-censorship assumptions.
| Proposal | What it changes | Protection and limitation |
|---|---|---|
| BIP360 P2MR | Removes Taproot's key path and commits to a script-tree root. | Reduces long exposure when keys stay hidden; does not add a post-quantum signature. Draft, not activated. |
| P2TRv2 | Keeps Taproot-like spending with PQ-capable leaves and later EC disabling. | Easier compatibility and fee profile, but the output key remains exposed until a future consensus action. |
| P2TRH or P2QR | Hashes the Taproot-like key, or disables elliptic-curve spending from the start. | Offers different security-efficiency tradeoffs; both remain design alternatives rather than deployed standards. |
| SHRINCS | Defines a SHA-256 hash-based signature with stateful and stateless paths. | Post-quantum authorization research, but signatures are large, state is delicate and integration is unspecified. |
| BIP361 | Sets phased deadlines for migration and legacy-signature restrictions. | Addresses incentives and timing, but depends on unfinished signature and rescue mechanisms. |
| DropKick | Commits secret ownership evidence before a delayed post-quantum rescue. | May cover some legacy outputs, not P2PK; requires PQ support and additional miner assumptions. |
What holders and operators can do now
Do not rush funds into an untested format or service claiming to be quantum-proof. No proposed PQ output is active. Avoiding key reuse, limiting xpub sharing and preserving seed backups reduce avoidable exposure while keeping migration possible.
Taproot's visible key is a long-exposure consideration, not a present exploit. Address choices also involve compatibility, privacy and fees. Follow maintained wallet guidance rather than move coins because of a qubit headline.
Custodians and developers should inventory exposure, identify cross-chain reuse, test crypto-agile wallets and plan customer migration. Follow work on Bitcoin Optech's topic page.
Bitcoin quantum-risk checklist
Use this checklist to separate prudent preparation from speculation. It is not a recommendation to move, buy or sell Bitcoin.
- Avoid address and key reuse
A previous spend can expose the public key protecting a remaining balance. Use maintained wallet software that generates fresh receive addresses.
- Limit xpub disclosure
An extended public key can reveal many derived public keys. Share wallet descriptors only with services whose access and retention you understand.
- Preserve recovery material
A future migration still requires legitimate control. Keep tested seed backups and documented recovery procedures; never enter a seed into a quantum-migration website.
- Separate logical from physical qubits
Treat any precise break date or qubit total skeptically unless it states architecture, error rate, runtime and error-correction assumptions.
- Check proposal status
Draft, BIP publication, Bitcoin Core implementation and mainnet activation are distinct milestones. None of the PQ spending proposals described here is active.
- Plan for operational migration
Institutions should inventory exposed keys, cross-chain reuse, hardware dependencies and the customer communications needed for a controlled upgrade.
Where TurboStrategy fits: execution software, not quantum security
TurboStrategy is not a quantum-security product. It does not make Bitcoin addresses, exchange custody, API keys or the Bitcoin protocol post-quantum, and it cannot protect coins from a future cryptographic break.
TurboStrategy provides software for a predefined BTC/USDC spot strategy after a customer connects a supported exchange, allocates capital and activates it. Assets remain at the customer's exchange. Customer-authorized API access is limited to trading; withdrawal and transfer permissions are not required.
Rules-based execution can help separate a trading process from alarming headlines. It cannot remove market, exchange, software, custody or cryptographic risk, and it guarantees no result. Review the full risk disclosure before using the service.
Conclusion: a real migration problem, not a present-day break
Bitcoin is not currently being cracked by quantum computers. The credible long-term threat is narrower and more concrete: Shor's algorithm could eventually forge the signatures that authorize spending, with already exposed public keys becoming attractive first targets.
The 2026 proposals divide the job into parts. P2MR and P2TRv2 explore where coins should live, SHRINCS explores how they could be signed, BIP361 explores how migration might be enforced and DropKick explores how some late movers might recover. Their tradeoffs show why no single proposal is a finished solution.
Preparation is rational because cryptographic migrations take years. Certainty about a Q-day forecast is not required, but accuracy matters: research models are not working attack machines, and draft Bitcoin proposals are not deployed protection.
Frequently asked questions
Can a quantum computer steal Bitcoin today?
No publicly demonstrated quantum computer can recover a secp256k1 private key today. The risk is based on future fault-tolerant machines and improving resource estimates, not a known current exploit.
How many qubits would it take to break Bitcoin?
There is no single number. Published 2026 estimates range from hundreds of logical qubits to tens or hundreds of thousands of modeled physical qubits, depending on architecture, error correction, runtime and other assumptions.
Does Shor's algorithm break Bitcoin?
A sufficiently capable machine running Shor's algorithm could derive a private key from a known ECDSA or Schnorr public key. It would attack spending authorization, not automatically rewrite Bitcoin's monetary rules.
Can Grover's algorithm take over Bitcoin mining?
Known Grover-based approaches provide a theoretical quadratic speedup, but current research finds their error-correction overhead and poor parallel scaling make them far less practical than signature attacks.
Are Taproot addresses quantum-vulnerable?
Taproot outputs expose an x-only elliptic-curve public key, so a future CRQC could target them while they remain unspent. That is a long-term exposure property, not evidence that Taproot can be attacked today.
Does using a fresh Bitcoin address help?
For hash-hidden output types, avoiding reuse can keep the public key concealed until spending and reduce at-rest exposure. It cannot prevent a sufficiently fast future on-spend attack once the key is revealed.
Is BIP360 P2MR quantum-proof?
No. P2MR removes the exposed Taproot key path and prepares a script upgrade path, but BIP360 does not add a post-quantum signature. Security still depends on the leaves used and on avoiding disclosure or reuse.
Is SHRINCS already supported by Bitcoin?
No. SHRINCS is a draft signature specification. Bitcoin would still need consensus integration, wallet support, fee rules, testing and activation before it could authorize mainnet transactions.
What should a Bitcoin holder do now?
Avoid address and key reuse, limit unnecessary xpub disclosure, maintain tested seed backups and keep wallet software current. Do not send funds to experimental schemes or services merely claiming quantum protection.