如何让比特币抵御量子计算机？三种主要格基签名方案对比

Original Author: Blockstream Team

Original Translation: Saoirse, Foresight News

Blockstream Research has published a comprehensive research report on lattice-based signatures for Bitcoin. This article summarizes the research content, core findings, and related recommendations. Thefull report can be accessed here.

Digital signatures are the core mechanism for authorizing transactions in Bitcoin, and the Schnorr and ECDSA signatures currently used for this purpose are extremely cost-effective. In 1994, Shor proved that a sufficiently powerful quantum computer could break both types of signatures. While there is still widespread debate about when such machines will be built, we need to develop a viable post-quantum signature deployment plan before the problem actually arrives.

Lattice-based signature schemes are a popular candidate to replace existing signatures. Lattice cryptography has a research history spanning over a century, and its cryptographic applications have been developed for nearly three decades. Within post-quantum cryptography, lattice-based signatures offer several advantages: the combined size of public keys and signatures can be as low as less than 1.6 kilobytes, and their algebraic structure holds promise for supporting multisignatures, threshold signatures, and succinct proofs in the future.

This report examines three schemes: Dilithium, Falcon, and Hawk. For readers unfamiliar with lattice cryptography, we explain the design philosophy of each scheme, provide a complete walkthrough of the algorithms, and analyze them from the perspectives of security, performance, and practical deployment (such as wallet key derivation). Among the three, which ones can actually be deployed on the Bitcoin blockchain?

Evaluation Criteria

Bitcoin imposes its own constraints on signature scheme selection. This evaluation is based on four core criteria:

• On-chain cost: One of the most important metrics is the total size of the public key and signature. When an output is spent, both the public key and signature are recorded on-chain, and full nodes need to download and store every byte. Verification overhead is equally critical: every signature must be verified by nodes across the entire network, and slow verification places a burden on the whole network.
• Implementation complexity: Whether a scheme can be implemented securely is of utmost importance. If the design requires floating-point operations or delicate Gaussian sampling, implementation errors or side-channel attacks such as timing analysis could leak keys. Implementation complexity is a factor that cannot be ignored for a smooth migration.
• Deployment risk: Actual integration into Bitcoin faces various practical obstacles: the choice of hash functions at the consensus level (most candidate schemes use SHAKE, while Bitcoin uses SHA-256), the reproducibility of signature results across platforms, and whether the signing program fits within the memory constraints of hardware wallets.
• Development potential: The vast majority of Bitcoin wallets use BIP-32 hierarchical deterministic mechanisms: from a single master public key, an infinite number of child public keys can be derived without ever touching the private key. Currently standardized post-quantum signature schemes do not natively support this feature, so we study the cost of adding this capability, and also examine various non-standard scheme variants that might offer greater benefits.

What Security Level Should Be Chosen?

Before comparing sizes, we first need to determine the target security level. This choice is not as simple as it appears. NIST divides security levels into categories 1-5; higher levels offer stronger security but come with larger keys and signatures.

We believe Bitcoin should adopt at least a Category 3 security standard. Bitcoin outputs may remain unspent for decades, and if advances in cryptanalysis cause a scheme's actual security level to decline, assets would be locked by weakened keys and exposed to risk over the long term. Lattice assumptions have already withstood nearly three decades of public cryptanalysis—longer than the research foundation behind Bitcoin's adoption of elliptic curves. However, the complex algebraic structure of lattices still leaves many potential avenues for future attacks, and we should not bet all of our long-term security on them.

Major mainstream products have made the same judgment. Apple's iMessage PQ3 protocol directly discards Category 1 lattice parameters and uses Category 3 and 5 parameters exclusively; Cloudflare uses ML-KEM-768 (Category 3) in its post-quantum TLS deployment, stating that while Category 1 appears secure today, a security margin must be reserved for decades of future cryptanalysis. Bitcoin's security time horizon is even longer than both of these.

Raising the security level comes at a cost. For example, moving Dilithium from Category 2 to Category 3 increases the total size by approximately 1.5 kilobytes. The report compares parameter sets across all security levels so readers can weigh the trade-offs themselves. The fate of Hawk proves that conservative security considerations are by no means an academic exercise.

Detailed Analysis of Candidate Schemes

Dilithium: The Simple Design

Dilithium, standardized by NIST as ML-DSA in the FIPS 204 standard, transplants Schnorr signatures' commitment-challenge-response paradigm onto module lattice arithmetic.

Its greatest feature is simplicity. All operations in Dilithium are integer-based: ring operations, matrix-vector multiplication, hashing, and rounding—no floating-point arithmetic, and no discrete Gaussian sampling required. It is easier to write secure, constant-time implementations. It is also the most widely deployed candidate, already integrated into OpenSSL, BoringSSL, AWS-LC, and Apple CryptoKit.

The cost is size. At Category 3 security, ML-DSA-65 has a 1952-byte public key and a 3309-byte signature, totaling 5261 bytes—approximately 55 times the size of Bitcoin's native public key + signature total, making it the largest of the three schemes at the same security level.

The most valuable aspect of Dilithium for Bitcoin: it is the only one of the three that comes close to implementing BIP-32-style key derivation. The re-randomizable key construction DilithiumRK can generate child keys from parent keys using only public information. The report analyzes three variants, including our proposed DilithiumRKS, where the derivation logic is entirely contained within the wallet software and only standard verifiers processing regular ML-DSA signatures are needed on-chain. However, none of the three are yet production-ready: two variants require modifications to the verifier, and DilithiumRKS itself lacks a complete unforgeability proof; all schemes rely on a network-wide shared matrix, which, while formally secure under the Module-LWE assumption, binds the security of all keys to a single instance. We believe that Dilithium-based public key derivation is currently only a proof of concept and cannot be deployed in practice.

Falcon: The Compact Scheme

Falcon, selected by NIST and standardized as FN-DSA, is the most compact of the three. Falcon-512 at Category 1 security has a combined public key and signature size of 1563 bytes; Falcon-1024 at Category 5 security totals 3073 bytes. Falcon-1024, with a higher security margin, is even smaller than Category 3 Dilithium.

Falcon takes a different approach from Dilithium: a hash-and-sign scheme based on NTRU lattices. The signer's private key is a short basis of the lattice; a message hash is mapped to a point in space, and the signer uses the short basis to find a lattice vector close to that point. The point and the nearby vector together form the signature; verification only checks that the vector belongs to the lattice and is sufficiently close. The implementation challenge lies in finding the vector without leaking information about the basis. Early schemes like GGH and NTRUSign simply took the nearest lattice point, and each signature leaked some geometric information. Falcon uses the GPV framework, sampling nearby vectors from a Gaussian distribution, which provably makes the sampled output independent of the basis and eliminates the leakage risk—but the sampler becomes significantly harder to implement.

The sampler is Falcon's engineering Achilles' heel. It operates in the complex Fourier domain and requires floating-point computation. Different processors, compilers, and compilation optimization options all cause inconsistencies in floating-point output. This is not just a compatibility issue—it is a security concern: the GPV security proof requires that, for the same digest, the signer never outputs two different short vectors; once signatures become deterministic, platform-induced floating-point rounding differences break this condition. There is a viable solution: deterministic Falcon can replace hardware floating-point with integer emulation, producing identical signatures on all platforms. The cost is an approximately 15x slowdown in signing speed and a 2x slowdown in key generation.

Importantly, verification is unaffected: Falcon verification is entirely integer-based, deterministic, and is the fastest among the candidate schemes. This asymmetry is very friendly to Bitcoin: signatures are performed once by the wallet when spending a transaction, while every signature must be verified by all full nodes across the network. A 15x slowdown in signing is a low-frequency cost, and trading it for cross-platform reproducibility and integer operations is, in our view, a reasonable trade-off. The floating-point issue is therefore an obstacle that can be solved through engineering, not a fatal flaw.

Two caveats: due to structural constraints, Falcon has no Category 3 parameters—only Category 1 or Category 5 options. Based on security margin considerations, we recommend Falcon-1024. Second, signing consumes significant memory: the sampler for the 1024 parameter set relies on a precomputed tree occupying approximately 90 kilobytes of memory. Hardware wallets can dynamically rebuild this tree branch by branch, reducing memory usage to 16 kilobytes, but this doubles signing time. Slower signing on hardware devices is a real cost, but it is acceptable.

Hawk: The Failed Scheme

Hawk aimed to combine the strengths of the other two schemes: Hawk-512 signatures are only 555 bytes—smaller than Falcon; the signing side uses all-integer operations with minimum memory usage of just 6 kilobytes. It was also the only lattice-based candidate remaining in the third round of NIST's additional signature competition, and the report devotes considerable space to it.

The cost lies in its security assumptions. Rather than relying on the well-studied NTRU and SIS problems that have withstood decades of cryptanalysis, it depends on the lattice isomorphism problem and the one-more-SVP assumption, both of which have relatively short research histories.

Just before the report was finalized, Straznickas and Weis from Anthropic discovered a structural flaw in Hawk's lattice construction: the SVP problem dimension actually required for key recovery was only half of what the designers had assumed. The key recovery security bits for the candidate parameter sets were significantly weakened. The researchers completed a full end-to-end key recovery attack against the challenge parameters HAWK-256, which are used for cryptanalysis purposes; even under attack, the officially proposed HAWK-512 and HAWK-1024 remain practically unbreakable. The Hawk team confirmed the validity of the attack and withdrew the scheme from the NIST process; the team stated that if the vulnerability were fixed by doubling parameters, Hawk's proud size advantage would completely disappear.

The report still retains the Hawk chapter because the attack targets the algebraic properties of a specific number field, not a wholesale rejection of the entire design paradigm. Whether a redesign can avoid the vulnerability remains an open question. The Hawk incident also intuitively validates our rationale for insisting on conservative security margins: a scheme can have excellent size and speed, and have gone through multiple rounds of standardization, yet a single paper can dramatically reduce its estimated security level.

Comparison Table of Schemes

All schemes in the table above (including SPHINCS+) are stateless signatures: the signer does not need to record past signatures. Stateful hash-based signatures like XMSS can achieve smaller signature sizes, but require maintaining signing state; see thespecial report on hash-based signatures for comparison.

Remaining Obstacles to Deployment

Falcon lacks a usable key derivation scheme. The only publicly available BIP-32-style Falcon derivation scheme re-randomizes the private key basis, dramatically inflating the signature norm bound and bloating on-chain signatures to approximately 23.7 kilobytes. Moreover, the scheme's parameters fail to meet its own security conditions, and fixing this issue would cause the size to balloon even further. There is currently no viable Falcon public key derivation implementation, which is the most valuable open problem identified in the report.

The Falcon standard has not been finalized. Although NIST has selected Falcon, the FN-DSA draft has not yet been officially released. Standardization will bring audited implementations, test vectors, and hardware-level support. Widespread adoption would reduce the risk and difficulty of integrating at Bitcoin's consensus layer. We recommend waiting for the official FN-DSA release—until then, Falcon remains in flux.

The Falcon-WS variant: This variant relaxes internal parameters and compensates with rejection sampling, compressing Category 1 total size to 1114 bytes and Category 5 to 2387 bytes—a further size reduction compared to original Falcon. This direction has research value, but it will not be included in the official standard and requires more cryptanalytic validation. Existing research has found vulnerabilities in the strong unforgeability proof of its derivative schemes (ordinary unforgeability is unaffected).

Will better schemes emerge in the future? Beyond the aforementioned schemes, the Fiat-Shamir family dates back to BLISS in 2013. The latest result from CRYPTO 2025 by Gärtner, based on well-established assumptions, achieves paper sizes comparable to Falcon. The fundamental obstacle to engineering deployment for this family is implementation security: BLISS was broken via side-channel attacks due to non-constant-time Gaussian sampling; subsequent schemes have not completely resolved this issue, and the latest result also notes that sampling-stage protection is even more difficult. Until this problem is solved, such schemes only hold theoretical appeal and are not suitable for deployment.

Lattice-based and hash-based signatures are complementary. Lattice-based signatures can serve as components of hybrid schemes. For example, in SHRINCS, the stateless recovery path currently uses SPHINCS+ signatures of several kilobytes; replacing them with Falcon (or Falcon-WS) signatures—which are smaller and faster to verify—significantly reduces the cost of the low-frequency recovery path without affecting the everyday usage path.

Research Conclusions

The ranking of lattice-based candidates is clear: Hawk withdrew from the competition after the attack by the Anthropic team; Dilithium has the lowest implementation difficulty and is the only scheme with research groundwork related to key derivation, but its size is not friendly to Bitcoin's on-chain overhead; Falcon combines compact size, fast verification, and mature security assumptions—and its main shortcoming, floating-point operations on the signing side, already has viable engineering solutions. If we had to choose a lattice-based signature scheme for Bitcoin today, we would select Falcon-1024.

For now, our view aligns with the hash-based signature report: the conservative short-term path remains hash-based signatures, with the most mature security assumptions and the lowest risk, suitable as a transitional solution. Once FN-DSA is officially finalized, with stable specifications, audited codebases, and hardware wallet support, Falcon will offer significant improvements over pure hash-based signatures; hybrid deployment is also possible, allowing the two signature systems to complement each other.