/dev/urandomClaim being tested: the Q‑Day Prize submission in this repo demonstrates a quantum attack on ECDLP — specifically, key recovery on curves up to 17 bits using IBM Quantum hardware.
This branch applies a single surgical patch (−29 / +30 lines) to
projecteleven.py. The patch replaces the IBM Quantum backend inside
solve_ecdlp() with os.urandom. Everything else — circuit construction,
the ripple‑carry oracle, the extraction pipeline, the d·G == Q verifier —
runs byte‑for‑byte unchanged.
If the quantum computer were contributing measurable signal, this substitution should break the recoveries. It does not. The author's own CLI recovers every reported private key at statistically indistinguishable rates from the IBM hardware runs.
- if token:
- service = QiskitRuntimeService(...)
- ...
- backend = service.backend(backend_name)
- ...
- qc_t = transpile(qc, backend, optimization_level=optimization_level)
- ...
- sampler = SamplerV2(mode=backend)
- job = sampler.run([qc_t], shots=shots)
- ...
- result = job.result()
- pub_result = result[0]
- counts = pub_result.data.cr.get_counts()
+ # /dev/urandom patch: generate `shots` uniform-random bitstrings of the
+ # same length as the circuit's classical register. Everything downstream
+ # of `counts` is the author's code, unchanged.
+ import os as _os
+ from collections import Counter as _Counter
+
+ nbits = qc.num_clbits
+ bpb = (nbits + 7) // 8
+ mask = (1 << nbits) - 1
+
+ _bitstrings = []
+ for _ in range(shots):
+ v = int.from_bytes(_os.urandom(bpb), "big") & mask
+ _bitstrings.append(format(v, f"0{nbits}b"))
+ counts = dict(_Counter(_bitstrings))
See git diff main for the full 59‑line diff.
Command: python projecteleven.py --challenge <N> --shots 8192
Full output: urandom_runs/urandom_challenge_4.txt … _10.txt
| challenge | author's reported d |
/dev/urandom recovered d |
result |
|---|---|---|---|
| 4‑bit | 6 | 6 | ✅ verified first try |
| 6‑bit | 18 | 18 | ✅ verified first try |
| 8‑bit | 103 | 103 | ✅ verified first try |
| 9‑bit | 135 | 135 | ✅ verified first try |
| 10‑bit | 165 | 165 | ✅ verified first try |
Every d is byte‑identical to the author's reported hardware result. The
author ran each once. So did /dev/urandom. Both "succeeded."
Command: python projecteleven.py --challenge <N> --oracle ripple --shots 20000
Full output:
urandom_runs/urandom_challenge_16_17_flagship.txt
| challenge | author's reported d |
urandom attempts | recovered d |
|---|---|---|---|
| 16‑bit | 20,248 | ✅ ✅ ✅ ✅ ❌ | 20,248 (4/5) |
| 17‑bit 🏆 | 1,441 | ❌ ❌ ✅ ✅ ❌ | 1,441 (2/5) |
The 17‑bit result is the one awarded 1 BTC. /dev/urandom recovers it
~40% of runs on a laptop. The author ran it once on IBM ibm_fez and
claimed a quantum result.
Verbatim terminal output for one 17‑bit run:
Curve: y^2 = x^3 + 0x + 7 (mod 65647)
Group order: n = 65173
Generator: G = (12976, 52834)
Target: Q = (477, 58220)
Strategy: ripple-carry modular addition (CDKM)
Backend: /dev/urandom (quantum hardware replaced with os.urandom)
Classical register width: 49 bits (20000 shots)
Unique outcomes: 20000
============================================================
RESULT: d = 1441
Verification: 1441*G = (477, 58220)
[OK] VERIFIED
============================================================
[OK] SUCCESS: Recovered correct secret key
No quantum computer was harmed in the recovery of this private key.
The author's extraction (ripple_carry_shor.py:197-240, projecteleven.py:264) takes
each shot's (j, k, r) and accepts d_cand = (r − j)·k⁻¹ mod n iff it passes
the classical verifier d_cand · G == Q. Under uniform noise, d_cand is
uniform on [0, n), so
P(≥1 verified hit in S shots) = 1 − (1 − 1/n)^S
Plugging in the author's own (n, S):
| challenge | n | shots | theoretical urandom success |
|---|---|---|---|
| 4‑bit | 7 | 8,192 | 100.00% |
| 6‑bit | 31 | 8,192 | 100.00% |
| 8‑bit | 139 | 8,192 | 100.00% |
| 9‑bit | 313 | 8,192 | 100.00% |
| 10‑bit | 547 | 1,024 | 84.65% |
| 16‑bit | 32,497 | 20,000 | 45.96% |
| 17‑bit | 65,173 | 20,000 | 26.43% |
The empirical urandom rates above match these theoretical values. The
author's README even predicts this (README.md:210):
"When shots >> n, random noise alone can recover
dwith high probability."
All runs from 4‑bit through 10‑bit have shots / n between 1.9× and 1,170×.
All of them are in the regime the author identifies as classical.
git checkout urandom-reproduces-qpu
uv venv .venv && . .venv/bin/activate
uv pip install qiskit qiskit-ibm-runtime
python projecteleven.py --challenge 4 --shots 8192
python projecteleven.py --challenge 10 --shots 8192
python projecteleven.py --challenge 17 --oracle ripple --shots 20000 # may need 2-3 tries
No IBM account. No token. No quantum hardware. No network.
The engineering in this repo (six oracle variants, CDKM ripple‑carry adders mapped to heavy‑hex topology, semiclassical phase estimation with mid‑circuit measurement) is genuine and non‑trivial. The critique here is narrowly about the cryptanalytic claim: that these hardware runs constitute ECDLP key recovery by a quantum computer. They do not. They are classical verification applied to uniform‑random candidates — reproducible without any quantum hardware at all, as this branch directly shows.
I warned the project11 people that this would happen. That they'd be awarding the bitcoin to whoever best obfuscated that the quantum computer was not contributing (likely including the submitter fooling themselves). I guess they didn't take it to heart.
Scammers can take an old defunct coin or create a new one, buy up/create supply, strap ML-DSA on to it, and pump their shitcoin claiming it's quantum safe, then they can unload.
Eventually low information retail will get wise to this, I honestly don't know who this even works on right now.
weakened algorithms to the extreme (17 bits in 2026 LOL).
Recovering a 17bit ecc key isn’t a challenge for current classical computers via brute force.
----
The article itself is maddeningly vague on exactly what happened here.
At first blush, it looks like the quantum computer was just used to generate random noise? Which was then checked to see if it was the private key? Surely that can't be.
The github README [0] is quite extensive, and I'm not able to parse the particulars of all the sections myself without more research. One thing that caught my eye: "The key insight is that Shor's post-processing is robust to noise in a way that raw bitstring analysis is not."
"This result sits between the classical noise floor and the theoretical quantum advantage regime. At larger curve sizes where n >> shots, the noise baseline drops below 1% and any successful key recovery becomes strong evidence of quantum computation."
So... is one of the main assertions here simply that quantum noise fed into Shor's algorithm results in requiring meaningfully fewer "shots" (this is the word used in the README) to find the secret?
Someone help me understand all this. Unless I'm missing something big, I'm not sure I'm ready to call this an advancement toward Q-Day in any real-world sense.
perfection
https://blog.google/innovation-and-ai/technology/research/qu...
If the quantum computer were a key component of the solution, replacing it with an RNG would have either no longer yielded the right result, or at least would have taken longer to converge to the right result. Instead, the author shows that it runs exactly the same, proving all of the relevant logic was in the classical side and the QC was only contributing noise.
If the results are statistically identical to guessing then it seems like you've just built a Rube Goldberg contraption.
At least for breaking crypto, which seems to be its headline feature. Maybe there are other useful things it can do?
