Marin Ivezic
Swap a 71-byte ECDSA (Elliptic Curve Digital Signature Algorithm) signature for a 2,420-byte ML-DSA one and almost every other design decision in Bitcoin moves with it. Block capacity, mempool sizing, address format, wallet backup semantics, and the schedule for moving several million coins out of script types that a quantum computer could eventually spend. That is why the post-quantum work on Bitcoin is a stack of coordinated changes at different levels of maturity, not a single patch.
This post walks the stack from the bottom up: the output type, the algorithm choice, the fee arithmetic, the UTXO migration schedule, and the emergency mechanisms that exist in case the schedule slips. A UTXO is an unspent transaction output, the individual coin-shaped unit that Bitcoin’s ledger actually tracks. A CRQC, a cryptographically relevant quantum computer, is a machine large and stable enough to run Shor’s algorithm against secp256k1 keys. Nobody has built one. The engineering below assumes somebody eventually will.
The Output Type Change
Bitcoin’s exposure problem is a question of when a public key becomes visible on the chain. Hashed address types keep the key hidden until the coin is spent. Taproot does not.
A Taproot output’s scriptPubKey carries a 32-byte tweaked public key in the clear, from the moment the output is created. Taproot then offers two ways to spend. The key path uses that key directly with a single Schnorr signature, which is cheap and small. The script path reveals one leaf of a Merkle tree of spending conditions, along with a control block proving that leaf belongs to the committed tree. Either way, the key was already published at funding time. A CRQC operator watching the chain could work on it at leisure.
BIP-360, the Bitcoin Improvement Proposal that defines the post-quantum output type, removes the key path. The output commits only to the Merkle root of a script tree. A Merkle root is a hash, and a hash gives an attacker nothing to factor. No public key appears at funding time. At spend time the transaction reveals the leaf script, the control block, and the signatures satisfying that leaf, and the key revealed there is a post-quantum key. The proposal has been through several revisions and the output type has been renamed along the way, so check the current draft rather than older commentary.
Two implementation details matter for anyone building against it. The output claims SegWit witness version 2, which means bech32m addresses beginning bc1z; version 0 gave us bc1q for P2WPKH and P2WSH, and version 1 gave us bc1p for Taproot. And the design keeps the tapscript machinery intact, so multisignature policies, timelocks, and the script constructions Lightning depends on survive the change rather than needing a parallel design.
What the new output type does not fix
It removes the at-rest exposure and, with a post-quantum leaf, the at-spend exposure too. It does nothing for the transaction that gets you there. When you sweep a legacy P2WPKH output into a new post-quantum output, that sweep publishes a classical public key in the mempool, and it stays exposed until the sweep confirms. Against a fast CRQC, that’s a race.
It also does nothing for coins whose keys are lost. Migration requires signing, signing requires the key, and the oldest pay-to-public-key outputs already have their keys published on-chain with nobody left to move them. How much supply sits in these categories is unknown, and published estimates differ widely by methodology. That’s a policy problem with no engineering answer.
Choosing a Signature Algorithm
BIP-360 defines where the signature goes. It does not settle which one. The size table is the first thing to look at, because size drives everything downstream.
| Scheme | Public key | Signature | Bytes per input |
|---|---|---|---|
| ECDSA (secp256k1) | 33 | ~71 | ~105 |
| Schnorr (BIP-340), key path | n/a (in the output) | 64 | ~64 |
| ML-DSA-44 | 1,312 | 2,420 | 3,732 |
| ML-DSA-65 | 1,952 | 3,309 | 5,261 |
| FN-DSA-512 | 897 | 666 | 1,563 |
| SLH-DSA-SHA2-128s | 32 | 7,856 | 7,888 |
The Schnorr row assumes a Taproot key-path spend, where the tweaked public key sits in the scriptPubKey rather than the witness, so only the signature is carried per input. Every other row carries both the public key and the signature in the witness.
ML-DSA, formerly CRYSTALS-Dilithium (Module-Lattice-Based Digital Signature Algorithm, FIPS 204), is the standards-stable baseline. It was finalised in August 2024, it supports deterministic signing, which removes a class of nonce-related side channels, and verification is fast. It is also the bulkiest of the two lattice options, at roughly 35 times an ECDSA signature.
FN-DSA (FFT over NTRU-Lattice-Based Digital Signature Algorithm, draft FIPS 206, formerly Falcon) is the compact option, about 2.4 times smaller per input than ML-DSA-44. The standard is not final, and the reason for the delay is the same reason wallet engineers should look closely: Falcon signing samples from a discrete Gaussian distribution using floating-point arithmetic, which is difficult to implement in constant time and unpleasant to port to the fixed-point microcontrollers inside hardware wallets. Verification is not the hard part. Signing is.
SLH-DSA, formerly SPHINCS+ (Stateless Hash-Based Digital Signature Algorithm, FIPS 205), rests only on hash function security, with no lattice assumptions underneath it. If lattice cryptanalysis advances further than expected, this one still stands. The price is a 7,856-byte signature in its most compact parameter set, and considerably more in the faster variants. As a routine spending path it isn’t viable. As a recovery leaf that gets used once, it is reasonable.
Agility is a property of the tree
Because the output commits to a Merkle root of scripts, one output can hold several spending paths using different algorithms, and only the leaf you actually use gets revealed. An ML-DSA path for normal spends, an FN-DSA path once FIPS 206 lands, an SLH-DSA path held in reserve, all under one address.
That agility is not free, and the cost is easy to size. The control block runs 33 bytes plus 32 bytes for each level of the Merkle path, so doubling the number of leaves adds 32 bytes to every spend. Four leaves cost 97 bytes of control block, sixteen cost 161. Build the tree with room for algorithms you have not chosen yet; against a 2,420-byte signature, 97 to 161 bytes of control block is negligible.
The Fee Arithmetic
Bitcoin blocks are capped at 4,000,000 weight units. Non-witness bytes cost 4 WU each and witness bytes cost 1 WU each, which is the SegWit discount, and it does most of the work absorbing post-quantum signatures.
Take a one-input, two-output spend. The non-witness skeleton runs around 137 bytes, so about 548 WU either way. A Schnorr key-path witness adds roughly 66 bytes, giving a total near 616 WU. The same shape with ML-DSA-44 in a script leaf carries a 2,420-byte signature, a 1,312-byte public key, the leaf script, and a control block, so call it 3,840 witness bytes and about 4,390 WU in total.
That’s roughly seven times the weight for one signature, and it scales per input rather than per transaction. A two-input spend roughly doubles the post-quantum portion while the skeleton barely moves. With FN-DSA-512 the same transaction lands near 2,200 WU, a little under four times the Schnorr baseline.
The witness discount keeps this inside the existing limit. It does not keep fees flat. Throughput falls by whatever factor the chosen algorithm implies, and fees rise to clear the same demand across fewer slots. The alternative is raising the weight limit, which reopens the block size argument that produced the 2017 chain split. Our view is that coupling a post-quantum migration to that fight is the fastest available route to no migration at all, and that the algorithm choice is where throughput should be won instead.
Migrating the UTXO Set
BIP-361, proposed by Jameson Lopp and co-authors as a legacy signature sunset, takes BIP-360 as a prerequisite and adds a schedule.
Phase A begins roughly three years after activation. The network stops accepting new outputs to quantum-vulnerable script types, so every new output has to be post-quantum. Existing legacy outputs stay spendable, and that window is when the migration happens.
Phase B follows about two years later. Legacy ECDSA and Schnorr verification is disabled at the consensus layer, and anything not migrated stops moving. Phase C, still at research stage, would let holders of frozen coins prove control of the original seed and authorise a migration without revealing a key.
The freeze is the contested part. Critics read it as confiscation and as a break with the promise that holding the key is sufficient forever. The authors argue that coins swept by a quantum attacker devalue every remaining coin, so inaction is not neutral either. Alternative proposals let dormant holders prove key control without moving funds, or drop the deadline and rely on voluntary upgrades. How this resolves will be decided socially, not technically.
For engineering teams the policy outcome changes the deadline and not the work. Either way you need an inventory: which outputs you control, which script type each one sits in, whether the key is recoverable or archived on paper in a vault, and how many transactions and how much fee a full sweep costs at several fee levels. Custodians and exchanges will feel this first, because insurers and regulated clients tend to ask for the inventory well before the consensus layer does.
Emergency Mechanisms
The schedule assumes an orderly sequence. Three mechanisms exist for the case where it isn’t.
Commit-delay-reveal reduces the mempool race during legacy sweeps. You first publish a commitment, a hash of the spending transaction, which reveals no key. After a mandatory delay of some number of blocks, you publish the full transaction. An attacker who sees only the commitment has nothing to attack, and by the time the key appears the commitment already fixes where the coins go. The cost is two confirmations and two on-chain footprints per payment, and the added latency interacts badly with Lightning’s timelock assumptions. It buys time rather than solving anything.
Proof of seed knowledge uses a zk-STARK, a proof that a statement is true which reveals nothing beyond that fact and which rests on hash functions rather than elliptic curves, so it is itself quantum-resistant. A prototype demonstrates proving that a given Taproot key was derived from a particular BIP-32 seed, without publishing the seed or the key. Proof generation currently takes tens of seconds and produces proofs measured in megabytes, both of which need substantial optimisation before on-chain verification is realistic. As a recovery route for frozen coins under a Phase C style mechanism, the shape is right.
Hash-based constructions inside existing script limits need no soft fork at all. One-time signature schemes built from hashes fit within Bitcoin’s current opcode and script size limits, which means a user can adopt quantum-resistant spending today at their own expense. The expense is real and the transactions are large, so this suits high-value transfers and rescue operations rather than routine payments.
Node and Network Effects
Transactions in the low thousands of bytes change operational assumptions well beyond fee estimation. Default mempool sizing, currently 300 MB in Bitcoin Core, holds far fewer post-quantum transactions and will need review. Compact block relay keeps working, because it transmits short transaction identifiers rather than transaction bodies, but the fallback path where a node has to request full transactions becomes considerably more expensive on constrained links.
Light clients fare better than you might expect. Witness data can be pruned by non-archival nodes, and client-side block filtering never downloaded witnesses anyway. The pressure lands on relay nodes, block template construction, and anyone running infrastructure on metered bandwidth.
Where to Start
If you build wallets, custody systems, or anything that signs Bitcoin transactions, three pieces of work don’t depend on how the consensus debate resolves.
Build the UTXO inventory now, by script type, with a recoverability flag against every key. Abstract the signature algorithm behind an interface in your address and signing layers, because the tree structure assumes you’ll be running more than one scheme at once and possibly swapping one out. And model the sweep: transaction count, total weight, and cost at several fee levels, so that when a migration window opens you’re executing a plan rather than writing one.
The cryptography here is largely settled. FIPS 204 and 205 are final, FIPS 206 is close, and the output type has a published proposal and working test implementations behind it. What remains open is governance, sizing, and schedule.
Our Bitcoin and digital asset migration training walks through exactly this material with working examples: script type inventory, signature sizing and fee modelling, tree design for algorithm agility, and the migration sequencing decisions custody teams face. You can see the current programs and enrolment options at quantumacademy.com/. For deeper technical background on the underlying schemes and the threat model, PostQuantum.com carries the long-form analysis.