Every "Quantum ECDLP" Demo Is Theater. Here's the Proof.
Read the original thread on X
By NVK · April 24, 2026 · Updated April 24, 2026
Someone submitted a Shor’s algorithm implementation to the Project Eleven challenge claiming to break 17-bit elliptic curve cryptography on a quantum computer. The code is public. I read it. The private key is solved classically before the quantum circuit even runs.
This isn’t a quantum attack. It’s a classical computation wearing a quantum costume. And the pattern repeats in every small-scale “quantum ECDLP” demonstration published to date.
Three problems. All fatal.
1. The Private Key Is Baked Into the Circuit
Every oracle strategy that actually ran on hardware — Dense, Permutation, Ripple-Carry — starts with enumerate_group(G). This function classically builds the complete table of curve points: [0, G, 2G, …, (n-1)G]. Then point_to_index maps each point back to its scalar multiple.
For the target point Q = d·G, calling point_to_index[Q] returns d — the private key. That’s the definition of solving the discrete logarithm problem. The “quantum circuit” that follows is reading the answer from a lookup table the classical code already computed.
The Ripple-Carry Shor circuit makes this explicit:
s = self._get_index(Q_power) # this IS d * 2^i mod n
qc.append(get_gate(s), target_qubits(k_reg[i]))
The value d × 2^i mod n is embedded as a compile-time constant into the controlled modular adders. The quantum computer isn’t finding d. It’s being told d.
The README claims “No knowledge of d is used — group indices are derived from public enumeration of G.” This is a sleight of hand. The enumeration IS the brute-force solution. For n = 65,173, it’s roughly 65,000 classical point additions. Trivial.
A genuine Shor circuit must use coordinate encoding — operating on the (x, y) representation of curve points using reversible arithmetic. No classical agent should ever need to know d to build the oracle. The only strategy in this repo claiming to do that (“Arithmetic”) was “verified via spectator simulation for primes up to p = 13.” It never ran at the headline sizes.
2. “Recovery” Is a Classical Verify Filter
In a real Shor’s algorithm, you extract the answer from the quantum measurement statistics using continued fractions or lattice reduction. You verify once at the end. The quantum part does the heavy lifting.
This implementation does the opposite. Every single shot — all 20,000 of them — is fed through a classical verifier:
d_cand = ((r - j) * k_inv) % n
if self._verify(d_cand): # d_cand * G == Q ?
candidates[d_cand] = count
_verify performs a classical elliptic curve multiplication and rejects everything that isn’t the true private key. The candidates dictionary has at most one entry. The brief’s language about taking the “mode of candidate d values across all shots” is rhetorical — there is nothing to take a mode over. It’s a boolean: did any shot happen to land on d?
This is not quantum signal extraction. It’s a classical exhaustive filter over the output space.
3. The 17-Bit “Success” Is Random Luck
The author concedes that gate fidelity across the full circuit is approximately 0.995^111,816 ≈ 10^−244. All 20,000 shots produce unique bitstrings. The output distribution is empirically indistinguishable from uniform random noise.
Under the null hypothesis — uniform random output fed through the classical verify filter — the probability of finding the private key is straightforward:
| Scale | Group size (n) | Shots | P(≥1 hit from pure noise) |
|---|---|---|---|
| 16-bit | 32,497 | 20,000 | 46% |
| 17-bit | 65,173 | 20,000 | 27% |
| Both succeeding | — | — | 12% |
“We broke 17-bit ECDLP with a quantum computer” is a coin flip weighted slightly worse than heads.
The 6-bit defense doesn’t hold either. The brief claims “4 out of 10 successes versus a 20% random baseline.” But the true random baseline for 6-bit with 8 shots over a 31-element group is 1 − (30/31)^8 ≈ 23.4%. Four successes in ten trials has a 95% confidence interval of roughly [12%, 74%] — statistically consistent with the classical baseline, not twice above it.
What a Real Attack Would Look Like
A genuine Shor-for-ECDLP implementation needs two things this repo lacks:
Coordinate-encoded oracles. The controlled group operations must work on (x, y) curve coordinates using reversible modular arithmetic — addition, multiplication, inversion, all built from Toffoli gates. No classical point_to_index lookup. The circuit builds the oracle without knowing d.
Phase estimation recovery. The measured (j, k) pairs are processed through continued fractions or lattice reduction to extract the period, then d. No per-shot d·G == Q filtering. The quantum signal, not the classical filter, finds the answer.
Nobody has demonstrated this beyond p = 13.
Where We Actually Are
The gap between “quantum ECDLP demo” and “quantum ECDLP attack” is not incremental. It’s architectural.
| What’s needed | Best estimate (2026) | Current hardware |
|---|---|---|
| Logical qubits | 1,193 – 1,450 | 48 (Quantinuum) |
| Physical qubits | 10,000 – 500,000 | 4,158 (IBM) |
| Circuit depth | Billions of gates | Thousands before decoherence |
| Error correction | Surface code / QLDPC | Early fault-tolerant demos |
Sources: CFS (EUROCRYPT 2026), Google QAI (Babbush et al.), Oratomic (Cain et al.), Gouzien & Sangouard (PRL 2023).
The honest timeline for cryptographically relevant quantum attacks on Bitcoin’s secp256k1 remains the 2030s, contingent on fault-tolerance breakthroughs that haven’t happened yet. The demos making headlines today are not steps toward that goal — they’re a different kind of computation entirely.
Previously: Part 1: No, A Quantum Computer Is Not Going to Steal Your Bitcoin · Part 2: The Hardest Problem Isn’t Quantum · Part 3: I Read Every Bitcoin Quantum Proposal