In standards literature, ‘quantum-resistant’ and ‘quantum-safe’ are often used interchangeably. But for protocol engineers, there is a useful distinction worth making: a cryptographic primitive can resist known quantum attacks while the wider system that deploys it can still contain quantum-vulnerable components.

Understanding this terminology is not an exercise in semantic pedantry. It directly affects how protocol engineers evaluate threat models, select signature schemes, and design state transitions.

P.S: I contribute to BTQ (Bitcoin Quantum), an open-source, post-quantum Layer 1 protocol built on the Bitcoin Core lineage that replaces ECDSA with NIST-standardized ML-DSA signatures. This article evaluates the underlying cryptographic definitions and protocol-level tradeoffs from an engineering perspective.

Defining quantum-resistant

Quantum resistance refers to specific mathematical primitives whose hardness assumptions remain computationally infeasible for both classical and quantum computers.

Classical public-key cryptography relies on computational problems that are easy to compute in one direction but hard to reverse without secret information. Bitcoin and Ethereum rely heavily on secp256k1 elliptic curve cryptography for digital signatures (ECDSA and Schnorr) and SHA-256/Keccak-256 for hashing.

In 1994, Peter Shor published an algorithm that solves prime factorization and discrete logarithms in polynomial time on a fault-tolerant quantum computer. Because ECDSA security relies directly on the discrete logarithm problem over elliptic curves, a sufficiently large quantum computer running Shor's algorithm can derive a private key from an exposed public key in shocking time.

To build a quantum-resistant primitive, cryptographers substitute discrete logarithms with mathematical structures for which no efficient quantum algorithm is known.

The primary families standardized by the National Institute of Standards and Technology (NIST) include:

1. Lattice-based cryptography: Systems like ML-DSA (formerly Dilithium) and ML-KEM (formerly Kyber) rely on the hardness of learning with errors (LWE) and vector reduction problems over high-dimensional lattices.
2. Hash-based signatures: Statefully managed or stateless systems like SPHINCS+ and SLH-DSA whose security reduces entirely to the collision and preimage resistance of underlying cryptographic hash functions.
3. Code-based cryptography: Systems built on the difficulty of decoding general linear codes, such as McEliece.

A primitive is considered quantum resistant when its security parameter provides a concrete classical and quantum bit-security margin (for example, NIST Security Category 2, 3, or 5) under current cryptanalytic lower bounds.

Defining quantum safe

Where quantum resistance describes a property of a mathematical primitive, quantum safety describes an end-to-end system property. A protocol is quantum safe only when every layer of its stack, state model, key generation path, and operational lifecycle remains secure against quantum attacks.

An application can integrate a quantum-resistant signature algorithm and still fail to be quantum safe due to implementation defects or architectural edge cases.

Consider the following structural vulnerabilities in UTXO-based blockchains:

Exposed public keys versus hashed address reuse

In Bitcoin, a standard Pay-to-Public-Key-Hash (P2PKH) address reveals only the hash of a public key (RIPEMD-160 of SHA-256). As long as funds sit unspent at a P2PKH address, the raw public key is not visible on the public blockchain. A quantum attacker running Shor's algorithm cannot invert the hash function to discover the public key.

However, the moment the UTXO owner broadcasts a spending transaction, the full public key is disclosed in the witness script or scriptSig. At that point, a race condition opens between the mempool and block confirmation: an attacker with a quantum computer could theoretically extract the private key from the mempool transaction and broadcast a competing transaction with a higher fee.

Furthermore, address reuse instantly collapses this key-hiding defense. If an address is reused, the raw public key was already exposed during the first spend, leaving all remaining UTXOs at that address vulnerable prior to spend creation.

Hierarchical Deterministic Key Derivation Standard BIP32/BIP44

Hierarchical Deterministic (HD) wallets rely on elliptic curve scalar multiplication to derive child keys from parent keys. Even if the signature scheme on-chain is replaced with a lattice-based algorithm, unhardened HD derivation paths that rely on classical math can expose master public keys if a single child private key is compromised.

A system is only quantum safe if its entire key lifecycle, key derivation trees, signature scripts, address constructions, and peer-to-peer transport layers are systematically insulated from quantum vector attacks.

The engineering tradeoffs of post-quantum state models

Transitioning a UTXO protocol from classical ECDSA to post-quantum signatures introduces substantial engineering constraints that must be handled transparently.

1. Signature and key sizes

ECDSA keys are 32 bytes and signatures are 64 to 72 bytes. Schnorr signatures in Taproot are 64 bytes. By contrast, NIST ML-DSA (Dilithium) signatures are significantly larger:

• ML-DSA-44 (NIST Security Category 2): Public key size is 1,312 bytes; signature size is 2,420 bytes.
• ML-DSA-65 (NIST Security Category 3): Public key size is 1,952 bytes; signature size is 3,309 bytes.
• ML-DSA-87 (NIST Security Category 5): Public key size is 2,592 bytes; signature size is 4,627 bytes.

This size differential represents a roughly 40x to 70x increase in signature footprint. In a blockchain context, larger signatures increase transaction weight, consume more block space, increase network propagation latency, and raise resource requirements for full nodes validating the chain.

2. Transaction formats and PSBT extensions

Integrating larger signatures into a UTXO model requires updated transaction serialization formats. Protocol implementations must update Partially Signed Bitcoin Transaction (PSBT) specifications to transport larger witness payloads and support new script types, such as Pay-to-Merged-Redeem (P2MR), which optimizes tree verification paths for lattice keys.

3. Replay protection and chain isolation

Deploying quantum-resistant signature schemes via hard forks or separate Layer 1 networks requires explicit, strict replay protection. Because transaction formats on a post-quantum network differ fundamentally from classical Bitcoin Core transaction formats, strict domain separation and chain ID enforcement must prevent cross-chain transaction replay.

Evaluating protocol readiness

When evaluating claims of post-quantum protection in distributed networks, engineers should look beyond broad terminology and audit concrete implementation details:

• Which NIST-standardized parameters are implemented for signatures?
• How does the protocol handle public key disclosure prior to block inclusion?
• What are the block size, weight units, and mempool eviction policies given larger witness payloads?
• Are key derivation standards explicitly documented and decoupled from secp256k1 assumptions?

Quantum resistance is the mathematical tool. Quantum safety is the overall engineering discipline required to deploy that tool reliably without degrading decentralization or protocol stability.