Bitcoin ECDSA under Quantum Threat: Which Post-Quantum Signatures Can a Developer Simulate?

Bitcoin's security for spending funds rests on ECDSA over secp256k1, and this scheme is understood to be breakable by Shor's algorithm run on a large enough quantum computer [2]. No cryptographically-relevant quantum computer (CRQC) exists today, and the gap between current hardware and such a machine is described as large [2]. This means the threat is not immediate, but developers and protocol designers who plan multi-year software or wallet lifecycles need an honest estimate of the runway available before a transition to post-quantum signatures becomes urgent.

Estimates of that runway disagree. One paper states that Bitcoin's elliptic curve signature scheme could be completely broken by a quantum computer as early as 2027 under the most optimistic estimate [7]; this figure is referenced again in Sections 3 and 8 of this note rather than restated in full. Another paper in this set emphasises instead that no CRQC exists and that the distance to one is large, without committing to a year [2]. These are different framings from different papers, one giving an optimistic-case date and the other emphasising present-day infeasibility, and a builder should treat 2027 as a lower bound under favourable assumptions rather than a consensus forecast.

The two halves of Bitcoin's security, signatures and proof-of-work, are not equally exposed. Shor's algorithm threatens the signature schemes ECDSA over secp256k1 and BLS over BLS12-381 [2], but the same category of attack does not apply to mining. Proof-of-work is described as relatively resistant to substantial quantum speedup over the next 10 years [7], and Grover's algorithm, the quantum method that in principle applies to search-like problems such as proof-of-work, does not meaningfully threaten it because its speedup is only quadratic, because it is undermined by fault-tolerant per-operation cost and a K√K parallelization wall, and because Bitcoin's difficulty adjustment cancels the speedup [2].

Because signatures and mining face such different risk profiles, the practical engineering priority is clear: work on post-quantum signature replacement, not on post-quantum mining. This shapes the rest of this note, which focuses on what a developer can build and measure today with post-quantum signature schemes in a simulated Bitcoin environment.

Two distinct algorithmic threats are discussed in the literature reviewed here, and they should not be conflated. Shor's algorithm is the one that matters for Bitcoin's signatures: it can break ECDSA over secp256k1 and BLS over BLS12-381 [2]. Quantum computers are, more generally, theoretically capable of breaking the underlying computational hardness assumptions for many existing cryptographic schemes [13]. Bitcoin's use of ECDSA specifically is called out as not post-quantum secure because of Shor's algorithm [12].

Grover's algorithm is the other quantum algorithm commonly discussed, but it targets a different part of the system: mining, not signing. It does not meaningfully threaten Bitcoin's proof-of-work, because its speedup is only quadratic, it is crushed by fault-tolerant per-operation cost and a K√K parallelization wall, and difficulty adjustment cancels the speedup [2]. The verified claim lists fault-tolerant per-operation cost as one of the crushing factors without further elaborating the mechanism, so no additional detail about why that cost runs slower than a classical chip is asserted here. Because Grover's algorithm concerns hashing-based search rather than the discrete-logarithm structure Shor's algorithm attacks, the two threats require entirely separate defences: post-quantum signatures for one, and essentially no change for the other over the horizon considered.

Not all coins on the network are equally exposed even under a worst-case break of ECDSA. Of Bitcoin's roughly six million quantum-exposed coins, only about 2.3 million are judged irreducibly at risk [2]. This matters for triage: a transition plan does not need to treat the entire supply as equally urgent, since a majority of exposed coins could plausibly be protected through mechanisms other than an immediate hard migration.

Ethereum's exposure profile differs again. Between 50 and 65% of Ether sits at key-revealed accounts that can adopt post-quantum protection [2]. This is a separate finding about a separate chain and should not be read across to Bitcoin's 2.3-million-coin figure, since the two papers describe different asset classes and different exposure mechanics even though they come from the same source [2].

One paper gives concrete hardware and power estimates for running Grover-style attacks against Bitcoin mining, which is useful for grounding how far current technology is from a practical attack on that side of the system. Bitcoin already faces a quantum threat through Shor attacks on elliptic-curve signatures, according to this paper [14], which is a restatement of the same finding already noted above [2] rather than an independent confirmation. At the most favourable partial-preimage setting the paper considers (b = 32, 2^224 marked states), a superconducting surface-code fleet would require about 10^8 physical qubits and about 10^4 MW [14].

When the setting is tightened to match Bitcoin's actual January 2025 mainnet difficulty (b about 79), the resource bill explodes to about 10^23 qubits and about 10^25 W [14]. This is many orders of magnitude beyond the most favourable case, and it illustrates concretely why proof-of-work is judged resistant to near-term quantum speedup: the theoretical quadratic advantage of Grover's algorithm is swamped by the physical resource requirements at realistic difficulty.

These two numbers, 10^8 qubits and 10^4 MW at the favourable setting versus 10^23 qubits and 10^25 W at mainnet difficulty, come from a single paper's own modelling assumptions and should be read as illustrating the scale of the gap rather than as a forecast of when any such fleet could exist. No claim in this set states a timeline for building such hardware. A builder should treat these numbers as a scale check, not as a project plan input.

Nothing in this evidence set gives a comparable hardware-cost estimate for a Shor's-algorithm attack on ECDSA signatures specifically, so a like-for-like cost comparison between attacking signatures and attacking mining cannot be made from these claims. The 2027 optimistic-case estimate for breaking ECDSA (Section 1) [7] and the mining hardware costs above [14] come from different papers using different methods, and they should not be merged into a single timeline.

NIST's process for standardising post-quantum cryptographic primitives began in December 2016 [12]. Out of that process, NIST selected three digital signature schemes for standardisation: Falcon, SPHINCS+, and CRYSTALS-Dilithium [13], and a review of the field highlights the same three algorithms, CRYSTALS-Dilithium, Falcon, and SPHINCS+, as the key ones to track in the NIST PQC process [20]. Dilithium in particular emerged as one of the winners of the NIST competition and is now standardized as ML-DSA (FIPS 204) [12], and it was identified as the primary choice for post-quantum digital signing [13].

Dilithium's security rests on three hardness assumptions: Module Learning with Errors (MLWE), Module Short Integer Solution (MSIS), and SelfTargetMSIS [13]. Of these, SelfTargetMSIS is novel, and while it is classically as hard as MSIS, its quantum hardness was previously unclear [13]. This gap matters for anyone relying on Dilithium's stated security level, because a scheme's classical hardness proof does not automatically extend to the quantum setting.

One paper in this set closes that gap directly: it provides the first proof of the hardness of SelfTargetMSIS, via a reduction from MLWE in the Quantum Random Oracle Model (QROM) [13]. This new security proof is applicable under the condition q = 1 mod 2n [13], so it does not cover every possible parameter choice, only those satisfying this modular condition. A builder choosing Dilithium parameters for a simulation should check this condition explicitly if the security proof is meant to apply.

The proof comes at a size cost. Under the same security level, the public key size and signature size are about 2.9 times and 1.3 times larger, respectively, than those proposed by Kiltz et al. [13]. This is a direct trade-off a builder must budget for: the stronger, more completely proven security guarantee produces bigger keys and bigger signatures than an earlier, less completely proven construction.

Beyond the three NIST-selected schemes, the literature also frames a broader trade-off between families of post-quantum schemes. Lattice-based schemes offer better computational efficiency, while code-based schemes provide stronger security guarantees at the cost of increased communication overhead [3]. This is a general framing from one paper about MANET authentication, not a Bitcoin-specific benchmark, but it sets useful expectations for anyone choosing a family of scheme to prototype: faster lattice-based schemes trade off against heavier-but-more-conservative code-based schemes.

Within the lattice family, CRYSTALS-Dilithium has been tested directly inside a Bitcoin transaction context, with a notable downside. One paper reports that CRYSTALS-Dilithium has the adverse limitation of causing Bitcoin's transaction efficiency to fall by 17 times [4]. This is a substantial efficiency hit, and it motivates work on more compact constructions built on top of Dilithium rather than using it unmodified.

One such construction is the LAS scheme proposed in the same paper. The proposed LAS scheme, based on CRYSTALS-Dilithium and a zero-knowledge Scalable Transparent Arguments of Knowledge (STARK) protocol, generates signatures with post-quantum security and small signature sizes [4]. The verified claim does not describe LAS as an aggregate-signature design, so this note does not characterise it that way; it combines CRYSTALS-Dilithium with a STARK proof layer specifically to counter the 17-times efficiency loss seen with unmodified Dilithium in the same paper's Bitcoin context.

A separate paper takes a different, storage-oriented approach to comparing schemes in a blockchain exchange setting. It compares NIST-recommended post-quantum signatures with ECDSA in a Bitcoin exchange scheme, recording hash values of signatures and public keys within the blockchain and storing their actual content using IPFS [6]. This architecture, hashes on-chain and full content on IPFS, is a distinct design choice from the LAS approach, aimed at controlling on-chain storage cost rather than signature size directly.

The most directly buildable reference point in this evidence set is a Python-based simulation study. In this environment, ECDSA, Falcon, CRYSTALS-Dilithium, and SPHINCS+ were analyzed in combination with quantum communication protocols BB84, E91, and SARG04 [1]. This pairing of post-quantum signature schemes with quantum key distribution protocols is a distinctive feature of this study and gives a developer a template for what to simulate and how to structure the comparison.

On raw speed, the baseline classical scheme still wins, with a caveat about durability. ECDSA remains the fastest baseline scheme but lacks quantum resistance [1]. This is the expected trade-off: classical elliptic-curve signing is computationally cheap but offers no protection once a CRQC exists.

Among the post-quantum candidates, SPHINCS+ stands out for security at a measured cost. SPHINCS+ provides the highest security with an expected overhead of 93.5% [1]. The paper does not state the exact unit or baseline this percentage is measured against (for example, whether it is signature size, computation time, or another metric), so a builder should treat 93.5% as a reported figure to reproduce and pin down experimentally, rather than as a self-explanatory number.

On the quantum communication side, one protocol was found to generalise best across transaction sizes. Among quantum protocols, BB84 achieved the best overall efficiency across transaction sizes [1]. Building on this, the study identifies two recommended integration pairs: BB84 and CRYSTALS-Dilithium for speed/security balance, and SPHINCS+ and E91 for maximum quantum resilience [1]. These two pairings give a developer two concrete starting configurations to reproduce, one tuned for throughput and one tuned for conservative security.

Bitcoin cannot simply swap its signature scheme overnight, since old coins are locked under the existing scheme and any change to consensus rules requires coordination. One proposed mechanism addresses this directly. The paper proposes a commit-delay-reveal protocol that allows users to move funds to a quantum-resistant signature scheme, functioning even if ECDSA is compromised, and implementable as a soft fork [15]. This is significant because it means the protection mechanism does not require a hard fork, and it is explicitly designed to still work even after ECDSA has already been broken, not only as a preventative measure beforehand.

This commit-delay-reveal design is a different kind of contribution from the signature-scheme benchmarks discussed elsewhere in this note. It is a migration protocol, concerned with how coins move from an old scheme to a new one under adversarial conditions, rather than a comparison of signature algorithms' speed or size. A builder interested in simulating a full transition, not just swapping signature libraries, should treat this as the relevant mechanism to prototype.

No claim in this set gives a performance number (latency, throughput, or storage cost) for the commit-delay-reveal protocol itself. This means a developer wanting to know its overhead would need to implement and measure it directly, since the existing evidence establishes only that the mechanism exists, what problem it solves, and that it can be deployed as a soft fork [15].

Combining this with the exposure figures discussed earlier gives a plausible (not evidenced-as-linked) picture of triage: a majority of exposed Bitcoin is not irreducibly at risk [2], and a soft-fork-compatible migration path exists for moving funds to quantum-resistant signatures [15]. These two findings come from different papers and are not linked by any claim in this set, so this note states them side by side without asserting that one enables or was designed to complement the other.

The single largest gap in this evidence set is the absence of any claim reporting a direct head-to-head test of a post-quantum signature scheme integrated into an actual, running Bitcoin node or full client, under Bitcoin's real consensus rules. The closest available evidence is a Python simulation environment [1] and a Bitcoin exchange scheme that records hashes on-chain and content on IPFS [6], both of which are testbeds or partial integrations rather than full-node deployments.

Estimates of when a break of ECDSA might occur disagree in framing. One paper gives 2027 as an optimistic-case estimate [7] (see Section 1), while another emphasises that no CRQC exists today and the gap to one is large without giving a year [2]. A builder should not average these or treat 2027 as an expected date; it is explicitly the most optimistic case in its source paper [7].

Several numbers in this set lack full methodological detail as stated. The 93.5% overhead figure for SPHINCS+ [1] does not specify its unit or baseline in the claim as given. The 17-times efficiency drop for CRYSTALS-Dilithium in a Bitcoin transaction context [4] and the 2.9-times and 1.3-times size increases for Dilithium's new security proof compared to Kiltz et al. [13] come from different papers with different baselines (a Bitcoin transaction-efficiency context versus a cryptographic size comparison against a specific prior proposal) and must not be compared to each other.

Finally, no claim in this set directly compares the cost of attacking Bitcoin's signatures via Shor's algorithm against the cost of attacking its mining via Grover's algorithm using the same units or assumptions. The mining-side hardware estimates [14] and the signature-break timeline [7] come from separate papers with separate methods. Any statement ranking which attack is more imminent or more resource-intensive than the other would be an inference this evidence does not support, and this note has deliberately avoided making that comparison.

1. Set the scope. Decide whether the project is a signature-scheme benchmark (following the Python simulation template [1]), a Bitcoin-transaction integration test (following the CRYSTALS-Dilithium and LAS approach [4]), or a storage-architecture test (following the hash-on-chain, content-on-IPFS design [6]). These are three distinct project shapes drawn from three different papers; pick one to avoid conflating their methods.
2. Choose the signature schemes to implement. At minimum, implement ECDSA as the baseline, plus the three NIST-selected post-quantum schemes: Falcon, SPHINCS+, and CRYSTALS-Dilithium [13] [1]. Use reference implementations for each; do not write new cryptographic primitives from scratch.
3. Check parameter conditions before trusting a security proof. If using Dilithium and citing its QROM security proof, confirm the parameter choice satisfies q = 1 mod 2n [13], since the proof in this paper is stated as applicable only under that condition.
4. Build the simulation harness in Python. Follow the structure of the reference study, which analyzed ECDSA, Falcon, CRYSTALS-Dilithium, and SPHINCS+ in combination with quantum communication protocols BB84, E91, and SARG04 [1]. Vary transaction size as an experimental parameter, since the reference study measured efficiency across transaction sizes [1].
5. Measure speed against the ECDSA baseline. Record signing and verification time for each post-quantum scheme relative to ECDSA. Expect ECDSA to remain fastest [1]; the goal is to quantify by how much each post-quantum candidate is slower under your own hardware and implementation, since the reference paper reports the ranking but a builder needs their own reproducible numbers.
6. Measure and report overhead precisely. When measuring SPHINCS+, report overhead with an explicit unit, for example bytes of signature size, or milliseconds of computation time, or bandwidth. The reference figure of 93.5% overhead [1] does not specify its unit in the claim as given, so define yours clearly to make the result reproducible and comparable.
7. Test the two recommended pairings. Reproduce the reference study's two integration configurations: BB84 with CRYSTALS-Dilithium for a speed/security balance, and SPHINCS+ with E91 for maximum quantum resilience [1]. Compare both against the ECDSA-only baseline on the same transaction workload.
8. If testing inside a Bitcoin transaction context, measure transaction efficiency directly. Prior work found that CRYSTALS-Dilithium caused Bitcoin's transaction efficiency to fall by 17 times when used directly [4]. Confirm whether your implementation reproduces a similar drop, and if so, consider whether an aggregate-signature or STARK-based wrapper, following the LAS design [4], is worth implementing to recover efficiency.
9. If testing a storage architecture, separate on-chain and off-chain data explicitly. Following the exchange-scheme design, store hash values of signatures and public keys on-chain, and store the actual signature and key content on IPFS [6]. Measure on-chain storage growth and IPFS retrieval latency separately.
10. If testing a migration mechanism, implement the commit-delay-reveal flow. This protocol allows users to move funds to a quantum-resistant scheme and is designed to work as a soft fork, even if ECDSA has already been compromised [15]. Simulate the commit, delay, and reveal phases on a testnet or private chain, and measure the delay window's effect on user experience and on attacker opportunity, since no source in this set reports this overhead directly.
11. Report every number with its exact experimental conditions. State the benchmark, the sample or workload, and the software/hardware setting for every measured value, following the pattern used throughout this note; do not report a bare percentage or multiplier without its source paper's stated context.
12. Common failure points to check. Confirm library versions of Dilithium, Falcon, and SPHINCS+ match the parameter sets referenced in the standardisation documents [13] [12]; confirm the QROM proof's modular condition if relying on it [13]; and keep the Grover's-algorithm-related mining threat entirely separate from the signature-scheme benchmarking work, since they address different parts of the system with different attack models [2].