Author: Blockstream Team
Compiler: Saoirse, Foresight News
The Blockstream Research team has released 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 by clicking here.
Digital signatures are the core mechanism authorizing Bitcoin transactions, currently fulfilled by Schnorr and ECDSA signatures at extremely low cost. In 1994, Shor proved that a sufficiently powerful quantum computer could break both types of signatures. While there is extensive debate about when such machines might become available, we need to develop a viable plan for deploying post-quantum signatures before the problem truly arises.
Lattice-based signature schemes are popular candidates to replace existing signatures. Lattice cryptography has over a century of research history, and its cryptographic applications have been developed for nearly three decades. Within the post-quantum cryptography landscape, lattice-based signatures offer several advantages: the total size of public keys and signatures can be as low as 1.6 kilobytes, and their algebraic structure holds future promise for supporting multi-signatures, threshold signatures, and succinct proofs.
This report studies three schemes: Dilithium, Falcon, and Hawk. For readers unfamiliar with lattice cryptography, we explain the design principles of each scheme, provide a complete introduction to their algorithmic processes, and analyze them from dimensions such as security, performance, and practical deployment (e.g., wallet key derivation). Among the three, which schemes can actually be deployed on the Bitcoin blockchain?
Evaluation Dimensions
Bitcoin has its own constraints on signature scheme selection. 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 overhead is also critical: every signature must be verified by network nodes, and slow verification speeds would burden the entire network.
- Implementation Complexity: The ability to securely implement a scheme is crucial. If a design requires floating-point arithmetic or delicate Gaussian sampling, implementation errors or side-channel attacks like timing analysis could leak the secret key. Implementation complexity is a non-negligible factor for a smooth migration.
- Deployment Risks: Practical integration into Bitcoin faces various real-world obstacles: consensus-level hash function choices (most candidate schemes use SHAKE, while Bitcoin uses SHA‐256), 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 the BIP‐32 Hierarchical Deterministic mechanism: a single master public key can derive an infinite number of child public keys without touching the private key. Currently standardized post-quantum signature schemes do not natively support this feature. Therefore, we study the cost of supplementing this capability; we also examine various non-standard scheme variants that might offer additional benefits.
What Security Level Should Be Chosen?
Before comparing sizes, we must determine the target security level. This choice is not as straightforward as it seems. NIST divides security levels into 1‐5; higher levels offer stronger security but come with 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 scheme's effective security level, assets would be locked with weakened keys, exposed to long-term risk. Lattice assumptions have undergone nearly three decades of public cryptanalysis, a longer history than that of elliptic curves when Bitcoin adopted them. However, the complex algebraic structure of lattices still harbors many potential avenues for future attacks; we should not stake all our security bets for the distant future on it.
Major mainstream products have made the same judgment. Apple's iMessage PQ3 protocol directly 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 currently seems secure, safety margins are needed for decades of future cryptanalysis. Bitcoin's security time horizon is even longer than both of the above.
Increasing the security level comes at a cost. For example, Dilithium's total size increases by about 1.5 kilobytes when moving from Level 2 to Level 3. The report compares parameter sets for all security levels, allowing readers to weigh the trade-offs. Hawk's experience proves that conservative security considerations are not merely academic.
Candidate Scheme Details
Dilithium: A Scheme with Simple Design
Dilithium was standardized by NIST as ML‐DSA in the FIPS 204 standard. It migrates the commitment-challenge-response paradigm of Schnorr signatures to module lattice arithmetic.
Its greatest feature is simplicity. All Dilithium operations are integer-based: ring operations, matrix-vector multiplication, hashing, rounding. There are no floating-point operations, nor discrete Gaussian sampling. This makes it easier to write secure, constant-time implementations. It is also the most widely adopted candidate, already integrated into OpenSSL, BoringSSL, AWS‐LC, and Apple CryptoKit.
The cost is larger size. Level 3 secure ML‐DSA‐65 has a 1952-byte public key and a 3309-byte signature, totaling 5261 bytes, approximately 55 times larger than the total 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 point of Dilithium for Bitcoin is that it is the only scheme among the three that is close to achieving BIP‐32 style key derivation. The rerandomizable key construction DilithiumRK can generate child keys from a parent key using only public information. The report analyzes three variants, including our proposed DilithiumRKS, where derivation logic resides entirely within the wallet software, and the chain only needs a standard verifier to handle ordinary ML‐DSA signatures. However, none are yet 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 formally binds the security of all keys to a single instance under the Module-LWE assumption, though it is considered secure. We believe that Dilithium-based public key derivation is currently only a proof-of-concept and cannot be deployed.
Falcon: A Compact Scheme
Falcon was selected by NIST, with the standardized name FN‐DSA. It is the most compact among the three. Level 1 secure Falcon‐512 totals 1563 bytes for public key plus signature; Level 5 secure Falcon‐1024 totals 3073 bytes. Falcon‐1024, with higher safety margins, is even smaller than Level 3 Dilithium.
Falcon adopts a different approach from Dilithium: a hash-and-sign paradigm based on NTRU lattices. The signer's private key is a short basis for a lattice; the message is hashed and mapped to a point in space, and the signer uses the short basis to find a lattice vector very 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 lies in finding the vector without leaking information about the basis. Early schemes GGH and NTRUSign directly took the nearest lattice point, leaking some geometric information with each signature. Falcon employs the GPV framework, sampling a nearby vector from a Gaussian distribution, provably making the sampling output independent of the basis, thus 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 can 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 signatures become deterministic, platform-induced floating-point rounding differences break this condition. A viable solution exists: deterministic Falcon can use integer emulation to replace hardware floating-point, producing perfectly consistent signatures across all platforms. The cost is about a 15x slowdown in signing speed and about a 2x slowdown in key generation.
Importantly, the verification phase 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 network-wide. A 15x slowdown in the infrequent signing operation, in exchange for cross-platform reproducibility and integer-only operations, is, in our view, a reasonable trade-off. Therefore, the floating-point issue is an obstacle solvable through engineering, not a fatal flaw.
Two notes: Due to structural constraints, Falcon lacks Level 3 parameters, only offering Level 1 or Level 5. Based on safety margin considerations, we recommend Falcon‐1024. Secondly, 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 about 16 kilobytes, but doubling signing time. Slower signing on hardware devices is a real cost but remains acceptable.
Hawk: A Scheme Declared Failed
Hawk aimed to combine the strengths of the other two schemes: Hawk‐512 signatures are only 555 bytes, smaller than Falcon; the signer side uses only integer operations, with a minimum memory footprint of only 6 kilobytes. It was also the only lattice-based candidate remaining in the third round of the NIST Additional Signature competition, and the report dedicates substantial space to its introduction.
The cost lies in its security assumptions. It does not rely on the decades-tested NTRU and SIS problems but on the lattice isomorphism problem and the one‐more‐SVP assumption, both with relatively shorter research histories.
Just before the report was finalized, Anthropic's Straznickas and Weis discovered a structural flaw in Hawk's lattice construction: the dimension of the SVP problem actually needed for key recovery is only half of what the designers assumed. The key recovery security bits for the candidate parameters were drastically reduced. The researchers completed a full end-to-end key recovery attack on the challenge parameter HAWK‐256 used for cryptanalysis; even under attack, 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 indicated that if the flaw were fixed by doubling parameters, Hawk's once proud size advantage would vanish completely.
The report retains the Hawk chapter because the attack targets the algebraic properties of a specific number field, not an outright rejection of this design paradigm. Whether a redesign could avoid the flaw remains uncertain. The Hawk incident also vividly confirms our reason for insisting on conservative safety margins: even a scheme with excellent size, speed, and having gone through multiple rounds of the standardization process can see its estimated security level drastically reduced by a single paper.
Scheme Comparison Table
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 signature state; refer to theHash-Based Signatures Special Report for a comparison.
Significant Obstacles Remain for Deployment
Falcon lacks a viable key derivation scheme. The only publicly available BIP‐32 style Falcon derivation scheme re-randomizes the secret key basis, drastically increasing the signature norm upper bound, causing on-chain signatures to balloon to about 23.7 kilobytes. Moreover, the scheme's parameters fail to meet its own security conditions; fixing this issue would cause the size to explode further. There is currently no feasible Falcon public key derivation implementation, which is the most valuable open problem raised in the report.
The Falcon standard is not yet finalized. Although NIST selected Falcon, the FN‐DSA draft has not been officially released. Standardization completion will bring audited implementations, test vectors, and hardware-level support. Widespread adoption reduces the risk and difficulty of integration into Bitcoin's consensus layer. 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, compensating with rejection sampling, reducing Level 1 total size to 1114 bytes and Level 5 to 2387 bytes, further shrinking compared to the original Falcon. This direction holds research value but will not be included in the official standard and requires more cryptanalysis validation. Existing research has found flaws in the strong unforgeability proof of a derived scheme (ordinary unforgeability is unaffected).
Will better schemes emerge in the future? Beyond the above schemes, the Fiat‐Shamir series, originating with BLISS in 2013, and the latest work by Gärtner presented at CRYPTO 2025, based on mature assumptions, achieve paper sizes comparable to Falcon. The root cause of the series' difficulty in practical engineering is implementation security: BLISS was previously broken via side-channel attacks due to non-constant-time Gaussian sampling; subsequent schemes have not completely resolved this issue, and the latest work also indicates higher difficulty in protecting the sampling step. Until these issues are resolved, such schemes only have theoretical appeal and are unsuitable for deployment.
Lattice-based and hash-based signatures can be complementary. Lattice-based signatures can serve as components in hybrid schemes. For example, in SHRINCS, the stateless recovery path currently uses multi-kilobyte SPHINCS+ signatures; replacing them with Falcon (or Falcon‐WS) signatures reduces size, speeds up verification, and significantly lowers the cost of the infrequently used recovery path, without affecting the daily use path.
Research Conclusion
The ranking of lattice-based candidate schemes is quite clear: Hawk exited the competition 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 not friendly to Bitcoin's on-chain costs; Falcon balances compact size, fast verification, and mature security assumptions; its main weakness – floating-point operations on the signer side – already has viable engineering solutions. If we must choose a lattice-based signature scheme for Bitcoin now, we would choose Falcon‐1024.
For the present moment, our view aligns with that of the hash-based signature report: the short-term conservative path remains hash-based signatures, with the most mature security assumptions and the 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 is also possible, allowing the two signature systems to complement each other.
