Time is running out for RSA and the Elliptic Curve Digital Signature Algorithm (ECDSA). They won’t survive a cryptographically relevant quantum computer (CRQC), and upgrades to our underlying cryptography, globally, have already begun. Right now, though, they’re tough to beat: keys are quick to create, signatures verify quickly, and they’re packed into just a few bytes. They’re also well-documented and battle-tested. The problem is that none of that helps against quantum attacks. To stay safe, we need “post-quantum” signature schemes. These schemes are based on lattice, hash, and multivariate constructions, among others, and they usually flip the trade-offs: keys get larger, signatures swell, and computations slow down. So how bad are the trade-offs for these post-quantum schemes, and how does that affect Bitcoin?
Post-Quantum Schemes
Post-quantum signatures are not yet implemented in Bitcoin, although several proposals have been put forward on how this might be done. Three clear options have emerged: ML-DSA, Falcon (soon to become FIPS-206 and also referred to as FN-DSA), and SLH-DSA. Other options are being considered by NIST, but these could be several years away and haven’t yet been thoroughly tested. Even the more “compact” candidates, like Falcon or ML-DSA, come with kilobyte-sized public keys and signatures. If you calculate the maximum number of transactions, Bitcoin’s practical transactions per second (TPS) could drop by an order of magnitude, unless something else is changed to compensate, such as bigger blocks, witness discounts, or off-chain channels. In other words, Bitcoin can handle post-quantum cryptography, but only if we accept either larger blocks or fewer on-chain transactions. Let’s dive into some actual numbers.
Table 1: This table shows a comparison of some of the key metrics for RSA and ECDSA to which post-quantum schemes should be compared to. The values for ECDSA were calculated from here and RSA from here.
Table 2: This table shows a comparison of some of the key metrics when discussing post-quantum cryptographic algorithms. All values were taken from here.
Tables 1 and 2 show some of the key metrics that matter when utilizing digital signature schemes. RSA is included as a comparison to ECDSA, although it matters significantly less in the context of blockchains. A few observations:
-
Even the smallest post-quantum candidate (Falcon) increases Bitcoin’s on-chain footprint: its 666-byte signature is already ~9× larger than today’s ECDSA signature.
-
ML-DSA-44 is reasonably fast for key generation, but its 2.4 kB signature and 1.3 kB public key would cut TPS by ~30×.
-
SLH-DSA-128s is a conservative option: a small public key paired with a signature of almost 8,000 bytes. It’s great for cases where few signatures are required; however, it becomes problematic in systems that require many signatures, such as Bitcoin.
-
ECDSA (the baseline row) shows how lean the incumbent really is: 64-byte signatures and keys, around 130,000 CPU cycles per signature generation, but with zero protection against quantum attacks.
In short, post-quantum safety does not come free: the trade-off is the size of the signature, and in all but one case, the size of the public key as well (SLH-DSA being the exception). While key generation is also slower in most cases, this does not directly affect the network, since keys are generated by users off-chain. Another key metric is signature verification time, as shown in Table 3. Falcon and ML-DSA are in the same ballpark as ECDSA, ML-DSA-44 is actually faster, while SLH-DSA-128s is roughly 40× slower.
Table 3: This table shows the number of CPU Cycles taken for a signature from the four algorithms listed to be verified. ECDSA was calculated from here, ML-DSA-44 and SLH DSA-128s values can be found here and for Falcon-512 here.
These numbers are all well and good for showing the differences of post-quantum schemes compared to their vulnerable counterparts. But what does this actually mean for Bitcoin?
Post-Quantum’s Impact on Bitcoin
Changing the cryptography Bitcoin uses will inevitably cause a range of problems, some well-understood, others not yet known. We’ll look at two of the major ones: the impact on full nodes and the reduction in TPS.
Table 4: This table shows how long it would take to sync the Bitcoin blockchain at its current height if we swap ECDSA with the three post-quantum schemes. ECDSA is given as a baseline to show the increase or decrease in sync time.
Note (rough-order estimates only): All figures in Tables 4 and 5 are back-of-the-envelope projections. They inherit several simplifying assumptions (e.g., identical hardware, identical software build, signature checks dominating validation, block structure and additional data, etc.). In practice, real-world values will vary due to hardware differences, algorithmic optimizations, network conditions, and the extra metadata each transaction may carry. Treat these numbers as indicative of scale rather than precise forecasts; they simply show the direction and rough magnitude of post-quantum impact on a Bitcoin full node.
Two key factors that impact a user’s ability to run a Bitcoin full node are how long it takes to sync, and how much data they are required to hold. Node sync time refers to the duration it takes a full node, starting from the genesis block, to validate all transactions and blocks and reach the current state of the blockchain. Table 4 translates the figures from Table 3 into practical, real-world implications. This is based on the time it currently takes a full node to sync using Bitcoin Core 26.0, approximately 8 hours and 35 minutes. The relative ratios for each post-quantum scheme (compared to ECDSA) are then applied to this baseline time.
ECDSA, Falcon-512, and ML-DSA-44 show roughly similar sync times, with ML-DSA being the fastest. SLH-DSA-128s, however, would take approximately 14 days based on this rough calculation. Of course, the numbers in Table 4 assume Bitcoin had implemented one of these schemes from genesis, which is not the case. Since signature checks dominate the validation work performed by full Bitcoin nodes, block download time can be assumed to have minimal impact on overall sync time.
The amount of information a full node needs to store, however, presents a far more concerning picture. Cryptographic information can take up to an estimated 55% of all data on the Bitcoin blockchain. Currently, a full Bitcoin node is required to hold 673.3 GB of data. We also know from Tables 1 and 2 that post-quantum public keys and signatures take up significantly more space than ECDSA. Table 5 shows the size of the Bitcoin blockchain if each of the post-quantum schemes were used from genesis. All three are in the terabyte range, with SLH-DSA reaching over 27 terabytes. While this is obviously not currently the case, and won’t affect any block prior to a post-quantum upgrade, it illustrates the scale of the problem post-upgrade. This problem could lead to the centralization of full nodes, as fewer individuals on standard hardware will be capable of running a node.
Table 5: This table shows an estimate of how large the Bitcoin blockchain would be if it had deployed the three post-quantum schemes from genesis.
Next, we’ll look at the more damaging of the two issues discussed in this post: block space, and by extension TPS.
Compared to many of the blockchains it inspired, Bitcoin has relatively low TPS. With one block every 10 minutes and an average of about 2,580 transactions per block, Bitcoin can handle 4.3 TPS. The maximum number of transactions a Bitcoin block can fit is 8,565, or about 14 TPS. Much of a transaction’s size comes from the cryptographic information provided by the sender to prove ownership of the UTXOs they are spending. ECDSA is relatively lean in terms of cryptographic data, as well as signature generation and verification times.
Given the stark differences shown in Tables 1 and 2 between post-quantum schemes and ECDSA in terms of key and signature sizes, it’s inevitable that fewer transactions will fit in a single block. As a result, the number of transactions per second that can be processed will also decrease. Table 5 and the corresponding Figure 1 show the impact of these post-quantum schemes on the number of transactions per block and transactions per second. It’s important to note that these values represent theoretical maxima, the absolute upper bound on transactions per block. In practice, the actual number is likely to be significantly lower. Some key points are:
- Falcon, the best alternative when considering block size and TPS, results in a 75.7% reduction in the number of transactions that can be held in a single block (assuming only SegWit transactions), meaning the TPS drops to 3.5. In reality, this would be closer to, or even below, 1 TPS, given that the theoretical 14.3 TPS with ECDSA translates to an actual rate of about 4.3 TPS.
- SLH-DSA, the worst option in terms of block size, reduces the number of transactions to just 484, a 94.3% reduction. This would mean a maximum TPS of less than 1, and as mentioned above, the real-world figure is likely to be significantly lower.
Figure 1: This graph shows the Number of transactions it is possible to pack into an optimally designed block for the various cryptographic schemes. This is considered with SegWit and its discount and without.
Table 6: This table shows the Number of transactions it is possible to pack into an optimally designed block for the various cryptographic schemes. This is considered with the SegWit discount (4x reduction in weight for signature and public key) and without. It also considers the Transactions Per Second (TPS)
These numbers speak for themselves, with a best-case scenario of a 75% drop in TPS. This would cause the mempool of unprocessed transactions to fill quickly, wait times for confirmation to increase, and miner fees to rise rapidly as users compete to reach the front of the queue. Bitcoin has never been known for a high TPS and has, at times, struggled to meet demand, leading to long wait times for transactions to be included in blocks. The inevitable integration of post-quantum schemes will cause this issue to become significantly worse without intervention. So what are the solutions?
The first is obvious: the dreaded phrase “increase block size.” This has been a contentious issue in Bitcoin for years, yet it remains the only “simple” lever available.
The second option could be increasing the Witness discount for these specific schemes. In truth, this has many of the same side effects as increasing the block size, such as putting additional pressure on full nodes to store significantly more data.
Another option would be to change the underlying protocol and cryptography completely by introducing new primitives such as zero-knowledge proofs. This might mitigate some of the issues post-quantum schemes pose but would likely be just as controversial, if not more so, than increasing the block size. Bitcoin would become reliant on an additional layer of cryptography and would require significant changes to the core protocol, far beyond adding a new post-quantum scheme. An example of one such proposal can be found here.
In summary, this is a necessary but costly upgrade for Bitcoin, technically and socially. Yet despite the cost, it is unavoidable.
It’s widely accepted by the teams working on this problem that these trade-offs are a necessary evil because the alternative, a quantum-vulnerable Bitcoin on Q-Day, is far worse.