Blockstream Research has narrowed the practical post-quantum signature choices for Bitcoin after ruling out Hawk, a compact lattice-based design that lost credibility following a newly disclosed structural weakness. Its assessment leaves Falcon and Dilithium as the main lattice candidates, with Bitcoin-facing trade-offs that divide sharply between transaction size, implementation safety, verification speed and wallet compatibility.
The review places Hawk’s collapse at the center of the comparison. Hawk had attracted attention for small signatures and a low memory footprint, qualities that would have limited the on-chain cost of a post-quantum upgrade. Research by Straznickas and Weis found a structural issue that reduces the effective shortest-vector-problem dimension available for key recovery to roughly half the level assumed by Hawk’s designers, cutting its estimated security margin.
Blockstream Research said the researchers demonstrated an end-to-end key-recovery attack against challenge parameters called HAWK-256. The work did not demonstrate equivalent practical breaks against the formal HAWK-512 and HAWK-1024 parameter sets. Yet the Hawk team subsequently withdrew its submission from the US National Institute of Standards and Technology’s post-quantum process, according to the assessment.
Fixing the weakness by substantially increasing Hawk’s parameters would erode the space efficiency that made it attractive. Hawk-512 had offered a 555-byte signature and a signer memory requirement of about 6 kilobytes. Blockstream Research concluded that the design is no longer a viable option for Bitcoin planning.
Bitcoin’s migration problem is measured in decades
Bitcoin currently uses Schnorr and ECDSA signatures to authorize transactions. Both are vulnerable in principle to Shor’s algorithm, the quantum-computing result published by Peter Shor in 1994 that could solve the mathematical problems underlying widely used public-key cryptography if sufficiently capable quantum machines become available.
Blockstream Research treats the issue as a migration and engineering problem rather than an imminent protocol emergency. Bitcoin outputs can remain unspent for decades, so the report argues that any eventual replacement should target at least NIST’s Level 3 security category. That standard creates a direct tension between cryptographic margin and blockchain space: the assessment estimates that raising Dilithium from Level 2 to Level 3 adds roughly 1.5 kilobytes to the combined public-key and signature data.
The researchers evaluated schemes according to four operational constraints: on-chain cost, implementation complexity, deployment risk and longer-term development potential. Public keys and signatures become transaction data when coins are spent, making their size especially consequential for a network in which every full node independently checks every signature.
Implementation concerns carry equal weight. Cryptographic designs that depend on floating-point arithmetic or delicate Gaussian sampling can create platform-specific behavior, side-channel exposure or correctness errors. Hardware wallets add another constraint because their memory and processing resources are limited compared with desktop systems.
Dilithium offers safer engineering at a large space cost
Dilithium, standardized by NIST as ML-DSA in FIPS 204, emerged as the simpler implementation candidate. The scheme uses integer-only arithmetic through signing and verification, avoiding the floating-point and sampling challenges associated with Falcon.
That implementation advantage comes with a substantial on-chain footprint. At NIST Level 3, the ML-DSA-65 parameter set uses a 1,952-byte public key and a 3,309-byte signature, for a combined 5,261 bytes. Blockstream Research estimates that this is about 55 times larger than Bitcoin’s current native public-key-plus-signature footprint.
Such an expansion would affect transaction construction more directly than ordinary fee-rate changes. Bitcoin fees are paid according to transaction weight, and a signature system that adds several kilobytes per spend would make common spending patterns materially larger. The cost would vary with fee conditions and the transaction’s broader structure, but the underlying data burden would be fixed by the signature choice.
Dilithium has another advantage in Bitcoin-specific research. It was the only lattice candidate in the review with a near-term body of work aimed at BIP-32-style hierarchical deterministic key derivation through rerandomizable keys. Hierarchical derivation lets wallets generate many addresses from a master seed without exposing private material.
The report examined proposals including DilithiumRK and DilithiumRKS, but found none ready to deploy. Some variants lack necessary security proofs, while others would require changes to validation rules. The designs also rely on a globally shared matrix, linking many keys to a common cryptographic instance and creating an additional deployment consideration.
Falcon preserves block space but raises wallet challenges
Falcon, selected by NIST under the name FN-DSA, offers the more compact route among the two remaining lattice options. Blockstream Research lists a combined public-key-and-signature size of 1,563 bytes for Falcon-512 and 3,073 bytes for Falcon-1024.
Falcon has no NIST Level 3 parameter set. The available choices correspond to Level 1 and Level 5, pushing Bitcoin developers toward Falcon-1024 if they prefer a higher security margin for long-lived outputs. Even at that setting, Falcon-1024’s combined data size is materially below ML-DSA-65’s 5,261 bytes.
Its main drawback lies in signing. Traditional Falcon implementations use floating-point operations in the Fourier domain during sampling, which can produce different results across hardware and software environments. Blockstream Research described a deterministic alternative that simulates the required behavior with integer arithmetic. The trade-off is performance: signing becomes about 15 times slower and key generation about twice as slow, according to the assessment.
Verification is more favorable. The report describes Falcon verification as deterministic, integer-only and the fastest among the reviewed candidates. That distinction is relevant to Bitcoin because a spender signs once, while the network’s full nodes verify the signature independently.
Memory remains a practical concern for constrained devices. Falcon-1024 can use a precomputed sampler tree requiring about 90 kilobytes. Rebuilding that structure dynamically reduces memory use to roughly 16 kilobytes, but doubles signing time.
Key derivation and standardization remain unresolved
Falcon also lacks a workable BIP-32-style derivation approach, according to the review. The only public construction examined would expand on-chain signatures to about 23.7 kilobytes by rerandomizing the private basis and increasing the norm bound. Blockstream Research said the proposed parameters fail the scheme’s own security conditions, while correcting them would increase the size further.
FN-DSA itself has not yet reached finalization, leaving audited implementations, official test vectors and broad hardware support incomplete. The report also discussed Falcon-WS, a non-standard variant with combined sizes of 1,114 bytes at Level 1 and 2,387 bytes at Level 5. Falcon-WS sits outside the official standard track and needs further examination following earlier work that found a flaw in a strong-unforgeability proof, although ordinary unforgeability was unaffected.
Blockstream Research’s near-term posture favors hash-based signatures as a lower-risk transition route while lattice schemes mature. It also considered hybrid constructions that could combine a lattice signature with a hash-based fallback, including recovery paths where a large SPHINCS+ signature is replaced by Falcon or Falcon-WS for infrequent recovery operations.
The assessment does not select a final Bitcoin signature scheme. Instead, it frames the present choice clearly: Dilithium reduces implementation risk but would impose a large and permanent data cost, while Falcon offers much smaller transactions and fast network verification but requires solutions for deterministic signing, wallet memory limits, standardization and hierarchical key derivation.
To deepen your understanding of quantum-era transaction security, explore our guide here next.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
