Shor's algorithm, explained for people who just want to know if their bitcoin is safe
Updated August 6, 2026
Before you read another word about quantum computers and bitcoin, do one thing: open the wallet checker and see whether your own address has ever spent, or whether it's a Taproot address. That single fact, exposed public key or not, matters more to your actual risk than anything below. Once you've checked, come back and we'll get into why it matters.
Shor's algorithm is the name that keeps coming up in these conversations, usually without much explanation of what it does. It's a mathematical procedure, published by Peter Shor in 1994, for a quantum computer to solve two related problems fast: factoring large numbers into their prime components, and solving what's called the discrete logarithm problem. Neither problem is hard for a classical computer because of some missing trick. They're hard because the work needed grows explosively as the numbers get bigger, to the point where even the fastest supercomputers on earth would take longer than the age of the universe on sufficiently large inputs. Shor's algorithm changes that growth curve entirely, for a quantum computer with enough stable qubits to run it.
Why this lands on Bitcoin's signatures specifically
Bitcoin's private and public keys are related through elliptic curve multiplication on a curve called secp256k1. Going from private key to public key is easy, computers do it instantly. Going the other direction, recovering a private key from a public key, is a discrete logarithm problem on that curve, and it's currently infeasible for any classical computer to do for a real Bitcoin key. That infeasibility is the entire basis of the security model. Anyone can see your public key, once it's exposed, and anyone can see the signatures you've published, but nobody can work backward to your private key.
Shor's algorithm is built for problems shaped exactly like this one. A sufficiently capable quantum computer running it against a known public key could, in principle, derive the matching private key. That's not a hypothetical weakness in some obscure corner of Bitcoin's design. It's a direct hit on the mechanism that lets you prove ownership of coins without revealing a secret. This isn't unique to Bitcoin either: Ethereum and most other major cryptocurrencies lean on elliptic curve cryptography with a similar exposure profile, so it's an industry-wide question rather than something specific to one chain.
Grover's algorithm is a different animal
People often lump Shor's and Grover's algorithms together because both come from the same corner of quantum computing, but they threaten very different things and by very different amounts.
- Shor's algorithm gives an exponential speedup against discrete logarithm and factoring problems. That's what breaks elliptic curve signatures, since those problems are the whole foundation.
- Grover's algorithm gives a quadratic speedup for searching an unsorted space, which is the relevant model for brute-forcing a hash function or a symmetric key. A quadratic speedup is real, but it's a much smaller jump. Doubling the size of a hash output roughly restores the original level of security against a Grover-equipped attacker.
That difference in degree is the whole reason the two threats get handled so differently. Bitcoin's addresses rely on hash functions (SHA-256 and RIPEMD-160, depending on address type) to compress a public key down into the string you actually share. Those hashes fall under Grover's weaker threat, not Shor's, and the fix if it's ever needed is comparatively mundane: use a longer hash, which the existing algorithms already support without any conceptual redesign.
| Property | Shor's algorithm | Grover's algorithm |
|---|---|---|
| Speedup type | Exponential | Quadratic |
| Targets | Discrete log and factoring problems (elliptic curve keys, RSA) | Unsorted search problems (hash functions, symmetric keys) |
| Relevant to Bitcoin | Public keys and signatures (secp256k1) | Address hashes (SHA-256, RIPEMD-160) |
| Practical fix if needed | New signature scheme entirely (see BIP-360 / BIP-361) | Larger hash output size |
Why hash-based security degrades gracefully and ECC doesn't
This is the part that actually explains why quantum computing is a genuine long-term problem for Bitcoin's signatures but only a mild inconvenience for its hashing. A hash function under Grover's algorithm gets weaker in a predictable, tunable way. You lose roughly half the effective bit strength of the output, and you can compensate simply by using a bigger hash to begin with. It's an engineering adjustment, not a philosophical one.
Elliptic curve cryptography under Shor's algorithm doesn't degrade, it collapses. There's no larger curve you can switch to that keeps you safe against a capable enough quantum computer, because the entire problem class the security rests on becomes efficiently solvable, not just harder. That's why the serious proposals aren't talking about tweaking secp256k1's parameters. They're talking about replacing the signature scheme with something built on different, quantum-resistant math entirely, the kind of approach reflected in the NIST-standardized post-quantum schemes like ML-DSA (Dilithium) and SLH-DSA (SPHINCS+) finalized in 2024, which Bitcoin's own draft proposals draw context from without having adopted one specifically.
Where this stands for Bitcoin today
Two Bitcoin Improvement Proposals, BIP-360 and BIP-361, sketch out a quantum-resistant address format and a migration path toward it. Both are still drafts, not activated rules, and specifics will likely keep changing. One especially contentious thread is what happens to coins in long-dormant, already-exposed addresses, most visibly the roughly 1.1 million BTC tied to Satoshi-era mining, untouched since around 2010. Some proposals would eventually restrict spending from such addresses if they aren't migrated within a set window, which runs against Bitcoin's long-standing norm that nobody decides whose coins are allowed to move.
None of this requires action from you today. No quantum computer that exists, or that's credibly expected within the next several years, can run Shor's algorithm against a real secp256k1 key fast enough to matter. Serious estimates for when a cryptographically-relevant quantum computer might exist range from several years to a decade or more, and that range should be treated as genuinely open, not settled in either direction. If you want plain unit math while any of this settles, the sats converter handles sats-to-BTC arithmetic with no price attached.
Shor's algorithm threatens elliptic curve signatures through an exponential speedup on the discrete logarithm problem, while Grover's algorithm imposes only a quadratic speedup on the hash functions Bitcoin addresses use, and that asymmetry is the entire reason one gets fixed with a bigger hash and the other requires a new signature scheme.