When discussing post-quantum cryptography in blockchain networks, conversations often drift into hype or alarmism. The reality for protocol engineers is far more grounded. Upgrading digital signatures from classical elliptic curve cryptography to quantum-resistant lattice schemes is not a free performance upgrade. It introduces concrete engineering costs: dramatically larger transaction sizes, elevated network bandwidth requirements, higher verification overhead, and fundamental changes to how wallet key derivation functions.
At BTQ, where we are building a post-quantum Layer 1 based on the Bitcoin model using NIST ML-DSA (formerly Dilithium) signatures, acknowledging these trade-offs candidly is necessary for building realistic, long-term infrastructure. In this article, I will break down the exact costs of transitioning a UTXO network to post-quantum signatures and how protocol design must adapt to handle them.
The fundamental shift from ECDSA to ML-DSA
Bitcoin relies on the Elliptic Curve Digital Signature Algorithm (ECDSA) over the secp256k1 curve. ECDSA provides exceptional efficiency. An ECDSA public key compressed is 33 bytes, and a signature is roughly 64 to 72 bytes. This compact footprint allowed early protocol designers to fit thousands of transaction inputs into modest block sizes.
However, ECDSA relies on the hardness of the discrete logarithm problem over finite fields. Shor’s algorithm, executed on a cryptographically relevant quantum computer, can solve discrete logarithms in polynomial time. Once a public key is exposed on-chain, a quantum adversary could derive the corresponding private key and forge signatures.
To mitigate this threat, the National Institute of Standards and Technology (NIST) conducted a multi-year standardization process, selecting Module-Lattice-Based Digital Signature Algorithm (ML-DSA), derived from the Dilithium construction, as the primary standard for general digital signatures.
ML-DSA relies on the hardness of lattice problems, such as Module Learning With Errors (M-LWE). While quantum-safe, lattice mathematical structures require significantly larger keys and signatures than elliptic curves.
Tradeoff 1: Signature size and public key footprint
The most immediate constraint when implementing ML-DSA is data volume.
Under ML-DSA-44 (the security level corresponding roughly to NIST Level 1), the parameters look as follows:
– Public key size: 1,312 bytes
– Signature size: 2,420 bytes
Compared to ECDSA, an ML-DSA-44 signature payload is more than 35 times larger, and the public key is roughly 40 times larger. At higher security levels, such as ML-DSA-87, signatures exceed 4,500 bytes.
In a UTXO-based network where spending an input requires presenting a public key and a signature in the witness data, transaction sizes scale quickly. A basic single-input, two-output transaction that takes roughly 200 virtual bytes under classical Bitcoin witness scripts requires several kilobytes of witness data when using ML-DSA.
Tradeoff 2: Block space, bandwidth, and fee dynamics
Larger signatures directly impact transaction throughput, node storage, and fee economics.
If a network maintains traditional block weight limits while moving to post-quantum primitives, transaction throughput per block inevitably drops. Alternatively, increasing the block size limit to preserve transaction throughput increases network bandwidth requirements for full nodes and miners.
Every node in a peer-to-peer network must download, validate, and store witness data. When average transaction sizes expand from hundreds of bytes to several kilobytes:
1. Initial Block Download (IBD) consumes significantly more network bandwidth and disk storage.
2. Mempool memory footprint increases for nodes holding pending transactions.
3. Block propagation times across the peer-to-peer network require optimization to avoid higher orphan block rates.
For users, fee calculation remains tied to transaction weight. Because witness data is larger, spending a UTXO secured by an ML-DSA signature costs more in absolute bytes than spending an ECDSA output, even if fee rates per byte remain low.
Tradeoff 3: HD wallet derivation limits
Beyond byte sizes, changing signature schemes impacts wallet architecture, specifically Hierarchical Deterministic (HD) key derivation defined in standard protocols like BIP-32.
BIP-32 relies on the algebraic properties of elliptic curve addition. Extended public keys (xpubs) allow wallets to derive child public keys without needing private keys. This unhardened child key derivation enables read-only watch wallets, merchant payment processors, and exchange deposit tracking without exposing master private keys.
Lattice-based algorithms like ML-DSA do not natively support this form of homomorphic public key tweaking. Without linear algebraic additions that preserve signature validity across derived keys, classical non-hardened child key derivation cannot be applied directly to standard ML-DSA keys.
As a result, HD wallets using ML-DSA must rely primarily on hardened key derivation, where deriving a child key requires access to the parent private key. This presents a real design constraint for read-only tracking infrastructure, requiring alternative architectures such as pre-derived public key lists or specialized derivation schemes.
Engineering around limitations in BTQ
Building BTQ on the Bitcoin UTXO model with NIST ML-DSA requires addressing these overheads directly rather than ignoring them.
1. Efficient witness structuring: We isolate ML-DSA signature payload handling within witness structures similar to Segregated Witness, ensuring signature data does not bloat base block size limits while keeping transaction parsing deterministic.
2. PSBT integration: Partially Signed Bitcoin Transactions (PSBTs) have been extended to support ML-DSA key materials and witness fields, enabling multisig and hardware wallet workflows to interact with larger keys during testnet iterations.
3. P2MR (Pay-to-Merkle-Root) constructions: By utilizing tree-based script commitments, public keys only need to be revealed upon spending, keeping unspent output state size manageable for full nodes.
4. Tooling adaptations in regtest: Developing local regtest environments allows developers to benchmark actual block propagation times, witness verification latencies, and mempool usage under heavy ML-DSA transaction loads.
Conclusion
Post-quantum security is an engineering trade-off, not a free software patch. Transitioning to quantum-resistant primitives like ML-DSA requires accepting larger signature sizes, altered wallet derivation mechanics, and higher bandwidth demands in exchange for long-term cryptographic durability.
By admitting these limitations upfront and benchmarking them transparently on regtest and testnet networks, developers can design protocols that are both functionally resilient and computationally practical long before cryptographically relevant quantum computers arrive.
Be the first to comment