Kardashev scale Quantum Computing for Bitcoin Mining

Abstract

Bitcoin already faces a quantum threat through Shor attacks on elliptic-curve signatures. This paper isolates the other component that public discussion often conflates with it: mining. Grover's algorithm halves the exponent of brute-force search, promising a quadratic edge to any quantum miner of Bitcoin. Exactly how large that edge grows depends on fault-tolerant hardware. No prior study has costed that hardware end to end. We build an open-source estimator that sweeps the full attack surface: reversible oracles for double-SHA-256 mining and RIPEMD-based address preimages, surface-code factory sizing, fleet logistics under Nakamoto-consensus timing, and Kardashev-scale energy accounting. A parametric sweep over difficulty bits b, runtime caps, and target success probabilities reveals a sharp transition. At the most favourable partial-preimage setting (b = 32, 2^224 marked states), a superconducting surface-code fleet still requires about 10^8 physical qubits and about 10^4 MW. That load is comparable to a large national grid. Tightening to Bitcoin's January 2025 mainnet difficulty (b about 79) explodes the bill to about 10^23 qubits and about 10^25 W, approaching the Kardashev Type II threshold. These numbers settle a narrower question than "Is Bitcoin quantum-secure?" Once Grover mining is lifted from asymptotic query counts to fault-tolerant physical cost, practical quantum mining collapses under oracle, distillation, and fleet overhead. To push mining into non-trivial consensus effects, one must invoke astronomical quantum fleets operating at energy scales that lie far above present-day civilization.

Figures (11)

• Figure 1: End-to-end Grover mining estimator. Difficulty and success targets feed the reversible hash oracle, Grover iteration planner, and surface-code lift; the resulting fleet sizing drives the power and energy tallies used in the Kardashev analysis. Dashed arrows mark feedback between iteration budgets and surface-code parameters when runtime caps shrink.
• Figure 2: Fleet qubits required to mine at various difficulty, runtime, and success targets for three surface-code architectures. To read a cell, choose difficulty bits on the horizontal axis and a runtime cap on the vertical axis, then read the color as the fleet physical-qubit demand; grey cells mark infeasible settings where a single Grover iteration already exceeds the wall-clock cap, and white contours label code distance. Each cell evaluates $r_{\mathrm{cap}}$ via Eq. \ref{['eq:grover-rcap']} and sizes fleets via Eq. \ref{['eq:fleet-success']}--Eq. \ref{['eq:fleet-machines']} with $P_1$ from Eq. \ref{['eq:single-machine-success']}. Rows vary the hardware platform; columns fix the target success probability $P_t$. A dashed vertical marker highlights the Bitcoin mainnet difficulty on 2025-01-01 ($D\approx 1.1\times10^{14}$, $b\approx78.6$) BlockchainComDifficultyBlockchainComChartsAPI.
• Figure 3: Runtime--qubit Pareto fronts extracted from the same sweep as Figure \ref{['fig:fleet-heatmap']}. To read a point, pick a runtime cap on the horizontal axis and follow the curve for a chosen difficulty (color) and architecture (line style) to the fleet-qubit demand on the vertical axis. Each panel fixes the target success probability $P_t$ and evaluates Eq. \ref{['eq:grover-rcap']} and Eq. \ref{['eq:fleet-success']}--Eq. \ref{['eq:fleet-machines']}; missing segments correspond to infeasible settings where a single Grover iteration exceeds the runtime cap. A dashed marker on the difficulty colorbar highlights the Bitcoin mainnet difficulty on 2025-01-01 ($b\approx78.6$) BlockchainComDifficultyBlockchainComChartsAPI.
• Figure 4: Full-history Bitcoin network hashrate from Blockchain.com (7-day smoothing as provided).
• Figure 5: Network power as a function of difficulty under three efficiency tracks.