Written by: Blockstream Team
Compiled by: Saoirse, Foresight News
Blockstream Research has published a comprehensive research report on lattice-based signatures for Bitcoin. This article summarizes the research content, key findings, and related recommendations. The full report can be accessed via the link.
Digital signatures are the core mechanism authorizing Bitcoin transactions, currently fulfilled by Schnorr and ECDSA signatures at minimal cost. In 1994, Shor proved that a sufficiently powerful quantum computer could break both types of signatures. While there is widespread debate about when such machines might become a reality, we need to develop a viable plan for deploying post-quantum signatures well before the problem truly arrives.
Lattice-based signature schemes are popular candidates to replace existing signatures. Lattice cryptography has a research history of over a century, with cryptographic applications developed for nearly three decades. Among post-quantum cryptosystems, lattice-based signatures offer several advantages: the combined size of public key and signature can be as low as under 1.6 kilobytes, and their algebraic structure holds promise for supporting multisignatures, 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 rationale of each scheme, provide a complete introduction to the algorithm processes, and analyze them from the dimensions of security, performance, and practical deployment (e.g., wallet key derivation). Among these three, which schemes could truly be deployed on the Bitcoin blockchain?
Evaluation Dimensions
Bitcoin has its own constraints for selecting signature schemes. This evaluation focuses 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 cost is also critical: every signature must be verified by all network nodes; slow verification would burden the entire network.
- Implementation Complexity: The ability to implement a scheme securely is crucial. If the design requires floating-point arithmetic or precise Gaussian sampling, implementation errors or side-channel attacks like timing analysis could leak the private key. To achieve a smooth migration, implementation complexity is a factor that cannot be ignored.
- Deployment Risks: Actual Bitcoin integration faces various practical hurdles: consensus-level hash function choice (most candidate schemes use SHAKE, while Bitcoin uses SHA-256), reproducibility of signature results across platforms, and whether the signing program fits the memory constraints of hardware wallets.
- Future Potential: The vast majority of Bitcoin wallets use the BIP-32 Hierarchical Deterministic (HD) mechanism: from a single master public key, infinite child public keys can be derived without touching the private key. Currently standardized post-quantum signature schemes do not natively support this feature. Therefore, we research the cost of supplementing this capability and also examine various non-standard scheme variants that might offer additional benefits.
Which Security Level Should Be Chosen?
Before comparing sizes, the target security level must be determined. This choice is not as straightforward as it seems. NIST categorizes security levels into 1-5; higher levels offer stronger security but correspond to larger key and signature sizes.
We believe Bitcoin should adopt at least Level 3 security. Bitcoin outputs may remain unspent for decades. If advances in cryptanalysis reduce the actual security level of a scheme, assets could be locked with weakened keys, exposing them to long-term risk. Lattice assumptions have endured nearly three decades of public cryptanalysis, longer than the research history of elliptic curves when Bitcoin adopted them. However, the complex algebraic structure of lattices still has many potential openings for future attacks; we should not bet all our security for the distant future on it.
Major mainstream products have made the same judgment. Apple's iMessage PQ3 protocol entirely discards Level 1 lattice parameters, using only Level 3 and Level 5 parameters throughout; Cloudflare uses ML-KEM-768 (Level 3) in its post-quantum TLS deployment, stating that while Level 1 appears secure now, safety margins are needed for decades of future cryptanalysis. Bitcoin's security time horizon is even longer than both of these.
Increasing the security level comes at a cost. For example, upgrading Dilithium from Level 2 to Level 3 increases the total size by about 1.5 kilobytes. The report compares parameter sets across all security levels, allowing readers to weigh the trade-offs themselves. Hawk's case proves that conservative security considerations are far from theoretical.
Detailed Analysis of Candidate Schemes
Dilithium: The Simple Design
Dilithium was standardized by NIST as ML-DSA in FIPS 204. It migrates the commitment-challenge-response paradigm of Schnorr signatures to module lattice arithmetic.
Its greatest feature is simplicity. All operations in Dilithium are integer-based: ring operations, matrix-vector multiplication, hashing, rounding—no floating-point arithmetic or discrete Gaussian sampling. This makes it 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 trade-off is larger size. Level 3 secure ML-DSA-65 has a public key of 1952 bytes, a signature of 3309 bytes, totaling 5261 bytes, which is about 55 times the size of Bitcoin's native public/private key + signature. It is the largest among the three schemes at the same security level.
The most valuable aspect of Dilithium for Bitcoin is: it is the only one of the three that is close to achieving BIP-32-style key derivation. Re-randomizable key constructions like DilithiumRK can generate child keys from parent keys using only public information. The report analyzes three variants, including our proposed DilithiumRKS, where derivation logic resides entirely within wallet software, and the chain only needs a standard verifier for regular ML-DSA signatures. However, none are ready for deployment: two variants require modifying the verifier, DilithiumRKS itself lacks a complete unforgeability proof; all schemes rely on a globally shared matrix, which, while formally secure under the Module-LWE assumption, binds the security of all keys to a single instance. We believe that key derivation based on Dilithium currently remains a proof-of-concept and cannot be deployed in practice.
Falcon: The Compact Scheme
Falcon was selected by NIST and standardized as FN-DSA. Among the three, it is the most compact. Level 1 secure Falcon-512 has a combined public key and signature size of 1563 bytes; Level 5 secure Falcon-1024 totals 3073 bytes. Falcon-1024, with a higher safety margin, is even smaller than Level 3 Dilithium.
Falcon adopts a different approach: a hash-and-sign paradigm based on NTRU lattices. The signer's private key is a short basis of the lattice; the message is hashed to a point in space, and the signer uses the short basis to find a lattice vector close to that point. The point and this nearby vector together constitute the signature; verification only checks that the vector belongs to the lattice and is sufficiently close. The implementation challenge is finding the vector without leaking information about the basis. Early schemes like GGH and NTRUSign directly took the nearest lattice point, each signature leaking some geometric information. Falcon uses the GPV framework, sampling the nearby vector from a Gaussian distribution, provably making the sampling output independent of the basis, eliminating the leakage risk, but significantly increasing the difficulty of implementing the sampler.
The sampler is Falcon's engineering weakness. It operates in the complex Fourier domain, requiring floating-point computation. Different processors, compilers, and compilation optimization options lead to inconsistent floating-point outputs. This is not just a compatibility issue but a security risk: the GPV security proof requires that for the same digest, the signer never outputs two different short vectors; once the signature becomes deterministic, floating-point rounding differences across platforms break this condition. Feasible solutions exist: a deterministic Falcon can simulate integers to replace hardware floating-point, producing identical signatures across all platforms. The cost is about a 15x slowdown in signing speed and a 2x slowdown in key generation.
Importantly, verification is unaffected: Falcon verification uses only integer operations, is deterministic, and is also the fastest among the candidates. This asymmetric characteristic is very friendly to Bitcoin: signing is performed once by the wallet when spending a transaction, while every signature must be verified by all full nodes on the network. A 15x slowdown in the low-frequency signing operation, in exchange for cross-platform reproducibility and integer arithmetic, seems a reasonable trade-off to us. Therefore, the floating-point issue is an obstacle solvable through engineering, not a fatal flaw.
Two caveats: Due to structural constraints, Falcon has no Level 3 parameters; one must choose Level 1 or Level 5. Based on safety margin considerations, we recommend Falcon-1024. Second, signing consumes significant memory: the sampler for the 1024 parameter set relies on a precomputed tree occupying about 90 kilobytes. Hardware wallets can dynamically rebuild this tree branch by branch, reducing memory usage to 16 kilobytes, but doubling signing time. Slower signing on hardware devices is a real cost but remains acceptable.
Hawk: The Failed Scheme
Hawk aimed to combine the advantages of the other two schemes: Hawk-512 signatures are only 555 bytes, smaller than Falcon; signing uses only integer operations, with a minimum memory footprint of just 6 kilobytes. It was also the only lattice-based candidate remaining in the third round of the NIST Additional Signature Competition. The report dedicates substantial space to introducing this scheme.
The cost lies in its security assumptions. It does not rely on the decades-tested NTRU or SIS problems but on the lattice isomorphism problem and the one-more-SVP assumption, which have a relatively shorter research history.
Just before the report was finalized, Straznickas and Weis from Anthropic discovered a structural flaw in Hawk's lattice construction: the actual dimension of the SVP problem needed for key recovery is only half of what the designers assumed. The key recovery security bits for the proposed parameter sets were significantly weakened. The researchers performed a complete end-to-end key recovery attack on the cryptanalysis challenge parameter HAWK-256; even though attacked, the formally proposed HAWK-512 and HAWK-1024 still cannot be practically broken. The Hawk team confirmed the attack's validity and withdrew the scheme from the NIST process; the team stated that if the vulnerability were fixed by doubling parameters, Hawk's originally touted size advantage would be completely lost.
The report retains the Hawk section because the attack targets specific algebraic properties of the number field and does not completely negate the design paradigm. Whether a redesign could avoid the flaw remains uncertain. The Hawk incident also vividly confirms our rationale for insisting on conservative safety margins: a scheme, even with excellent size, speed, and having gone through multiple rounds of standardization, can see its estimated security level drastically reduced by a single paper.
Comparison Table of Schemes
All schemes in the above table (including SPHINCS+) are stateless signatures: signers do not need to record past signatures. Stateful hash-based signatures like XMSS can achieve smaller signature sizes but require maintaining signing state; refer to the hash-based signature thematic report for a comparison.
Multiple Hurdles Remain for Deployment
Falcon lacks a usable key derivation scheme. Currently, the only publicly available BIP-32-style Falcon derivation scheme re-randomizes the private key basis, drastically increasing the signature norm upper bound, inflating on-chain signatures to about 23.7 kilobytes. Moreover, the parameters of this scheme do not meet its own security conditions; fixing this would further explode the size. There is currently no viable Falcon public key derivation implementation, which is also the most valuable open problem highlighted in the report.
The Falcon standard is not yet finalized. Although NIST selected Falcon, the FN-DSA draft has not been officially published. Standardization completion will bring audited implementations, test vectors, and hardware-level support. Widespread deployment can reduce the risk and difficulty of Bitcoin consensus layer integration. We recommend waiting for the official release of FN-DSA; until then, Falcon remains in a state of flux.
Falcon-WS variant: This variant relaxes internal parameters and compensates with rejection sampling, compressing Level 1 total size to 1114 bytes and Level 5 to 2387 bytes, further reducing volume compared to the original Falcon. This direction has research value but will not be included in the official standard and requires more cryptanalysis. Research has already found flaws in the strong unforgeability proof of its derivative schemes (ordinary unforgeability is unaffected).
Will better schemes emerge in the future? Apart from the above schemes, the Fiat-Shamir series originated as early as 2013 with BLISS. The latest result proposed by Gärtner at CRYPTO 2025, based on mature assumptions, has paper sizes comparable to Falcon. The root cause of this series' difficulty in engineering implementation is implementation security: BLISS was previously cracked via side-channels due to non-constant-time Gaussian sampling; subsequent schemes have not completely resolved this vulnerability, with the latest work also indicating higher difficulty in protecting the sampling stage. Until this issue is resolved, such schemes only possess theoretical appeal and are unsuitable for deployment.
Lattice-based 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 several KB in size; replacing them with Falcon (or Falcon-WS) signatures offers smaller size, faster verification, and significantly reduces the low-frequency recovery path overhead without affecting the daily-use path.
Research Conclusion
The ranking of lattice-based candidate schemes' strengths and weaknesses is clear: Hawk dropped out of contention after the attack by the Anthropic team; Dilithium has the lowest implementation difficulty and is the only one with a research foundation related to key derivation, but its size is unfriendly to Bitcoin's on-chain costs; Falcon balances compact size, fast verification, and mature security assumptions; its main weakness—floating-point operations on the signing side—already has feasible engineering solutions. If we had to choose a lattice-based signature scheme for Bitcoin now, we would choose Falcon-1024.
For the present, our view aligns with the hash-based signature report: the short-term conservative route remains hash-based signatures, with the most mature security assumptions and lowest risk, suitable as a transitional solution. After FN-DSA is formally finalized, with stable specifications, audited codebases, and hardware wallet support, Falcon would offer significant improvements over pure hash-based signatures; hybrid deployment could also be adopted, allowing the two signature systems to complement each other.
