Written by: Blockstream Team

Translated by: Saoirse, Foresight News

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

Digital signatures are the core mechanism for authorizing transactions in Bitcoin, with Schnorr and ECDSA signatures currently serving this function at a very low cost. In 1994, Shor proved that a sufficiently powerful quantum computer could break both types of signatures. While there is still widespread discussion about when such machines might become available, we need to develop a viable post-quantum signature deployment plan before the issue actually arrives.

Lattice-based signature schemes are popular candidates to replace existing signatures. Lattice cryptography has over a century of research history, with cryptographic applications developing for nearly thirty years. In post-quantum cryptographic systems, lattice-based signatures have many advantages: the total size of the public key and signature can be less than 1.6 kilobytes, and their algebraic structure is expected to support multi-signatures, threshold signatures, and succinct proofs in the future.

This report studies three schemes: Dilithium, Falcon, and Hawk. For readers unfamiliar with lattice cryptography, we explain the design concepts of each scheme, provide a complete overview of the algorithm processes, and analyze them from dimensions such as security, performance, and practical deployment (e.g., wallet key derivation). Which of the three schemes can actually be deployed on the Bitcoin chain?

Evaluation Dimensions

Bitcoin has its own constraints when selecting signature schemes, and this evaluation focuses on four core criteria:

• On-chain Cost: One of the most important indicators is the total size of the public key and signature. When outputs are spent, both the public key and signature are recorded on-chain, and full nodes need to download and store every byte. Verification overhead is also crucial: every signature must be verified by all network nodes, and slow verification speeds can burden the entire network.
• Implementation Complexity: Whether the scheme can be implemented securely is vital. If the design requires floating-point operations or intricate Gaussian sampling, any implementation errors or timing attacks can leak keys. To achieve a smooth migration, implementation complexity is an important factor that cannot be overlooked.
• Deployment Risks: When Bitcoin is actually integrated, various real-world obstacles will arise: the choice of hash functions at the consensus level (most candidate schemes use SHAKE, while Bitcoin uses SHA-256), the reproducibility of cross-platform signature results, and whether the signature program is compatible with the memory limitations of hardware wallets.
• Development Potential: The vast majority of Bitcoin wallets use the BIP-32 hierarchical deterministic mechanism: through a single master public key, an unlimited number of sub-public keys can be derived without touching the private key. Currently standardized post-quantum signature schemes do not natively support this feature, so we examine the cost of supplementing this capability; we also consider various non-standard scheme variants that may yield additional benefits.

What Level of Security Should Be Chosen?

Before comparing sizes, the target security level must be determined, a choice that is not as straightforward as it seems. NIST divides security levels into 1-5; the higher the level, the stronger the security, but the corresponding keys and signatures will also be larger.

We believe Bitcoin should adopt at least the 3rd level security standard. Bitcoin outputs may go unused for decades; if advancements in cryptanalysis lead to a decrease in the actual security level of the scheme, assets may be locked by weakened keys, exposing them to long-term risks. Lattice cryptography has withstood nearly thirty years of open cryptanalysis, which is even longer than the research accumulation when Bitcoin adopted elliptic curves. However, the complex algebraic structure of lattice cryptography still presents numerous vulnerabilities that could be exploited in the future; we should not place all our security bets on it for the distant future.

Major mainstream products have made the same judgment. Apple’s iMessage PQ3 protocol directly discarded the 1st-level lattice parameters, using only 3rd and 5th-level parameters throughout; Cloudflare uses ML-KEM-768 (3rd level) in its post-quantum TLS deployment, indicating that while 1st level currently seems secure, they want to maintain safety margins for cryptanalysis over the coming decades. Moreover, the security time span for Bitcoin is even longer than for either of the two.

Enhancing the security level comes at a cost. For instance, transitioning Dilithium from 2nd to 3rd level increases the total size by approximately 1.5 kilobytes. The report compares the parameter sets across all security levels, allowing readers to weigh the trade-offs. Hawk’s experience demonstrates that cautious security considerations are not merely theoretical.

Detailed Candidate Schemes

Dilithium: A Simply Designed Scheme

Dilithium has been standardized by NIST as ML-DSA in the FIPS 204 standard, migrating the commitment-challenge-response paradigm of Schnorr signatures to modular lattice arithmetic.

Its greatest characteristic is simplicity. All computations in Dilithium are integer calculations: ring operations, matrix-vector multiplication, hashing, rounding, with no floating-point operations or discrete Gaussian sampling required. It is easier to write a secure, constant-time implementation. It is also the most broadly implemented candidate scheme, already integrated into OpenSSL, BoringSSL, AWS-LC, and Apple CryptoKit.

The downside is a relatively large size. For 3rd level security, ML-DSA-65 has a public key of 1952 bytes, a signature of 3309 bytes, totaling 5261 bytes, approximately 55 times the total size of Bitcoin's native public/private key + signature, making it the largest among the three schemes at the same security level.

The most valuable aspect of Dilithium for Bitcoin is that it is the only scheme among the three that closely approaches the implementation of BIP-32 style key derivation. The re-randomized key construction DilithiumRK can generate sub-keys from a parent key using only public information. The report analyzes three variants, including our proposal DilithiumRKS, where the derivation logic is entirely handled within wallet software, requiring only standard validators to process regular ML-DSA signatures on-chain. However, none of the three has reached deployment standards: two variants require modifications to the validator, and DilithiumRKS itself still lacks a complete unforgeability proof; all schemes rely on a shared matrix across the network, which, although formally secure under the Module-LWE assumption, binds the security of all keys to the same instance. We believe that the current state of public key derivation based on Dilithium is merely proof of concept and cannot be deployed in practice.

Falcon: A Compact Scheme

Falcon has been selected by NIST, with the standardized name FN-DSA, and among the three, it is the most streamlined. The public key and signature for 1st level secure Falcon-512 total 1563 bytes; for 5th level security, Falcon-1024 totals 3073 bytes. The Falcon-1024 with higher security margins is even smaller than the 3rd level Dilithium.

Falcon takes a different approach than Dilithium: it is based on the NTRU lattice's hash-signature scheme. The private key of the signer is a set of short bases of the lattice; the message is hashed to map to a point in space, and the signer utilizes the short basis to find a vector close to that point. The point and this nearby vector together form the signature; verification checks whether the vector belongs to the lattice and is sufficiently close. The challenge in implementation lies in finding the vector without leaking information about the basis. Earlier schemes like GGH and NTRUSign directly select points from the lattice, leaking some geometric information with each signature. Falcon uses the GPV framework to sample nearby vectors from a Gaussian distribution, proving that the sampled output is independent of the basis, thereby eliminating leakage risks, but this significantly increases the difficulty of sampler implementation.

The sampler is a shortcoming for Falcon on the engineering side. It requires floating-point calculations in the complex Fourier domain. Different processors, compilers, and compilation optimization options can produce inconsistent float output results. This is not just a compatibility issue, but a security concern: the GPV security proof requires the signer never to output two different short vectors for the same hash; if the signature becomes deterministic, discrepancies from platform floating-point rounding will compromise this condition. There are feasible solutions: deterministic Falcon can use integers to simulate hardware floats, producing completely consistent signatures across all platforms. The trade-off is that signature speed decreases by about 15 times, and key generation speed decreases by about 2 times.

Importantly, the verification step is unaffected: Falcon verification is performed entirely using integer operations, resulting in certainty and being the fastest among the candidate schemes. This asymmetric feature is very friendly to Bitcoin: signatures are executed once by the wallet at the time of spending, while each signature needs to be verified by all nodes in the network. A signature slowing down by 15 times is a low-frequency overhead, trading it for cross-platform reproducibility and integer operations seems reasonable in our view. Therefore, floating-point issues are obstacles that can be resolved through engineering methods, not fatal flaws.

Two points to note: due to structural constraints, Falcon does not have 3rd level parameters, only allowing choices of 1st or 5th level. Based on security margins, we recommend Falcon-1024. The second point is that signatures will consume a lot of memory: the sampler for the 1024 parameter set relies on a pre-computation tree, using about 90 kilobytes of memory. Hardware wallets can dynamically rebuild this tree down each branch, compressing memory usage to 16 kilobytes, but the signing time will double. The slowdown of signing on hardware devices is a real cost but is still acceptable.

Hawk: A Failed Scheme

Hawk aimed to combine the advantages of the other two schemes: the Hawk-512 signature is only 555 bytes, smaller than Falcon; all operations on the signing side are integer calculations, with a minimum memory footprint of only 6 kilobytes. It is also the only remaining lattice candidate in the third round of NIST’s additional signature competition, and the report dedicates considerable space to introducing this scheme.

The cost lies in the security assumptions. It did not adopt the NTRU or SIS problems, which have been tested against decades of cryptanalysis, but instead relies on the lattice isomorphism problem and the one-more-SVP assumption, both of which have a relatively short research history.

Just before the finalization of the report, Anthropic's Straznickas and Weis discovered structural flaws in Hawk's lattice design: the dimension of the SVP problem that must be solved for key recovery is only half of what the designer envisioned. The key recovery security bit of the candidate parameter set has been significantly weakened. The researchers completed a full end-to-end key recovery attack on the challenge parameter HAWK-256 used for cryptanalysis; even when attacked, the formal proposals HAWK-512 and HAWK-1024 still could not be realistically broken. The Hawk team confirmed the attack's validity and withdrew the scheme from the NIST process; the team stated that fixing the vulnerability by doubling the parameters would completely eliminate Hawk's proud size advantage.

The report retains the sections related to Hawk, as the attack targets specific algebraic characteristics of the number field and does not entirely negate this design paradigm. Whether a redesign can circumvent the vulnerabilities remains undecided. The Hawk incident also intuitively confirms our reason to insist on a conservative security margin: even if a scheme has excellent size and decent speed and has completed multiple rounds of standardization, a single paper can dramatically lower its estimated security level.

Comparison Table of Schemes

All schemes in the above table (including SPHINCS+) are stateless signatures: the signer does not need to record past signatures. State-based hash signatures like XMSS can achieve smaller signature sizes but need to maintain signature state; refer tothe report on hash-based signatures for comparisons.

Numerous Obstacles Remain for Implementation

Falcon lacks a usable key derivation scheme. Currently, the only publicly available BIP-32 style Falcon derivation scheme performs re-randomization on the private key base, dramatically increasing the upper limit of signature norms, resulting in on-chain signatures swelling to about 23.7 kilobytes. Moreover, the parameters of this scheme do not meet its own security conditions, and fixing this issue would cause the size to soar further. There is currently no viable implementation of Falcon public key derivation, which is also the most valuable problem raised by the report to address.

The Falcon standard has not been finalized. Although NIST has selected Falcon, the FN-DSA draft has not been formally published. Only after standardization is completed will there be audited implementations, test vectors, and hardware-level support. Widespread implementation can reduce the risks and difficulties of integrating with Bitcoin's consensus layer. We recommend waiting for the official release of FN-DSA; before that, Falcon remains in a state of flux.

The Falcon-WS variant: This variant relaxes internal parameters, compensating by refusal sampling, reducing the total size for 1st level to 1114 bytes and 5th level to 2387 bytes, further decreasing size compared to the original Falcon. This direction has research value but will not be included in the official standard, requiring more cryptanalysis validation. Existing research has found vulnerabilities in its strong unforgeability proof for derivation schemes (ordinary unforgeability is unaffected).

Will better schemes emerge in the future? Aside from the above schemes, the Fiat-Shamir series originated from the 2013 BLISS, with the latest results proposed by Gärtner at CRYPTO 2025, based on mature assumptions, can match Falcon in size. The root of difficulty in engineering these schemes lies in implementation security issues: BLISS had once been attacked through side channels due to non-constant time Gaussian sampling; subsequent schemes have not thoroughly resolved this risk, and the latest results indicate that fortifying the sampling stage is even more complex. Until these issues are resolved, such schemes only possess theoretical appeal and are not suitable for deployment.

Lattice-based signatures and hash-based signatures can complement each other. Lattice-based signatures can serve as components in hybrid schemes. For example, in SHRINCS, the stateless recovery path currently uses SPHINCS+ signatures sized in several KB; replacing them with Falcon (or Falcon-WS) signatures results in smaller volume, faster verification, and significantly reduced low-frequency recovery path overhead, without affecting daily usage paths.

Research Conclusions

The advantages and disadvantages of lattice candidate schemes are very clear: Hawk has exited the competition following an attack from the Anthropic team; Dilithium has the lowest implementation difficulty and is the only scheme with a foundational study on key derivation, but its size is not friendly to on-chain costs for Bitcoin; Falcon balances compact size, fast verification, and mature security assumptions; its main shortcoming—floating-point computation on the signature side—now has viable engineering solutions. If we must select a lattice signature scheme for Bitcoin now, we would choose Falcon-1024.

Currently, our view aligns with the hash-based signature report: the conservative route in the short term remains hash-based signatures, with the most mature security assumptions and lowest risks, suitable as a transitional scheme. Once FN-DSA is officially finalized and has a stable specification, an audited codebase, and hardware wallet support, Falcon will bring significant improvements compared to pure hash signatures; hybrid deployment can also be used to let the two types of signature systems complement each other.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。