Post-quantum signatures, settled on paper, unsettled on chain

NIST rounds out the signature finalists

Updated 6 October 2026

That is a finished standard, not a finished Bitcoin. It is not a fork, not a wallet update, and not a key migration you can run from a watch-only tab.

What NIST actually closed in October 2026

NIST's post-quantum cryptography programme has been running since 2016. The third round, the one that started in 2020 and was supposed to settle the signature question, finally narrowed to a defensible list in the second week of October 2026. The agency confirmed ML-DSA, derived from CRYSTALS-Dilithium, as the primary lattice-based signature standard. SLH-DSA, derived from SPHINCS+, was confirmed as the hash-based fallback. FN-DSA, derived from FALCON, was held back for a later publication track because of its tighter implementation tolerances, not because the mathematics failed review.

For the Bitcoin beat, the headline is the size of the gap. ML-DSA public keys start at 1,312 bytes for the parameter set that NIST calls ML-DSA-44. SLH-DSA signatures start at 7,856 bytes for the small variant. secp256k1 public keys are 33 bytes in compressed form, and signatures are 64 to 72 bytes depending on DER encoding. Even a generous 65 byte witness assumption puts secp256k1 two orders of magnitude under the lattice signature sizes, and a full order of magnitude under the hash-based ones.

This is the architectural point. A Bitcoin box does not care about the standardisation calendar. A box opened by a secp256k1 signature continues to open with a secp256k1 signature. The question is what the key looks like, not what the box is willing to accept. The address label still says what it says, the witness still parses as it parsed yesterday, and the dust limit, which currently sits at 546 sats for legacy outputs, still applies.

There is a temptation, on the back of a NIST announcement, to read backwards into Bitcoin. CatBitcoin has covered the runway counter and the BIP 360 frozen vault proposal already. Both of those still stand. Nothing in the October 2026 list changes the count of satoshis that are provably behind P2PK lockboxes, or the cost for a sufficiently large fault-tolerant machine to grind through one of those boxes before its owner moves the coins.

Why ML-DSA is not secp256k1, and why that matters for boxes

The cryptographic core of ML-DSA is a module-lattice problem. The security argument reduces, in the random oracle model, to the hardness of finding short vectors in a module lattice over a cyclotomic ring. secp256k1 reduces, in the generic group model, to the elliptic curve discrete logarithm problem. The two proofs have nothing in common, and the parameter sets are not interchangeable. A box labelled for secp256k1 cannot be opened by an ML-DSA signature, even if a future Bitcoin soft fork were to add ML-DSA as a witness programme.

This is the part the standards press tends to flatten. A NIST standard is a tool in the toolbox. It is not, on its own, a Bitcoin migration. A migration would require a proposal that maps current boxes to new boxes, and a way to spend the old boxes before they are opened by a quantum machine that the proposal's authors cannot themselves run.

BIP 360, the proposal CatBitcoin has covered in detail, uses a different primitive for its hash-based commitment scheme. It is, in spirit, closer to SLH-DSA than to ML-DSA, but it is not either of them. The reason is calibration. SLH-DSA's smallest secure parameter set still produces signatures that would bloat a Bitcoin block. A 7,856 byte signature, multiplied by the average number of inputs per block, would break the existing block weight ceiling, which currently sits at 4,000,000 weight units and was last adjusted by the SegWit soft fork in 2017.

So the cat watches two clocks. One is the NIST clock, which now shows a finalised primary. The other is the runway counter, which still tracks the number of satoshis held in P2PK lockboxes. The clocks are not synchronised, and a careless reader will mistake one for the other.

Where the box stays closed under the new standard

Three places. The first is the cold storage box, the kind that sits behind a hardware wallet, a metal seed plate, and a passphrase that nobody pastes into a watch-only field. The owner has the key, the box is closed, and the standardisation of ML-DSA changes nothing about the bytes that travel when the box is opened.

The second is the watch-only box. CatBitcoin has been clear that watch-only is a window, not an opening. The October 2026 NIST list does not make a watch-only wallet into a wallet. It does not give a viewer the ability to sign, and it does not let an xpub leak close the box any faster. The window stays a window, the box stays closed, and the warning still stands.

The third is the exchange-held box. The address label on the chain still points to a script, and the script still requires a signature that only the exchange's key-management stack can produce. NIST standards do not give the exchange a reason to migrate early, and they do not give the user a reason to panic. They do, however, give the exchange's compliance team a calendar entry.

The clause in the BIP 360 draft that just became more readable

BIP 360's frozen vault clause asks the chain to refuse, after a configured block height, any spend from a P2PK-style output whose public key is exposed on the chain. The mechanism is a per-output covenant that activates when the output has not moved for a set period and that triggers a refund to a quantum-safe script. The clause was already present in the working draft, but the October 2026 NIST closure gives it a sharper risk model.

Before the list closed, the argument against the clause ran like this. Without a settled standard, the covenant would lock coins against an attacker whose primitive is not yet decided. After the list closed, the argument runs like this. ML-DSA is the likely primitive, the lattice parameters are now frozen, and a covenant that funnels exposed keys to an ML-DSA-style output is at least pointing at a concrete target. Whether the target becomes a Bitcoin target is a separate question, and one the BIP 360 authors have not pretended to answer.

The runway counter, which CatBitcoin tracks as a separate column, sits in the high single-digit billions of US dollars as of early October 2026. The exact figure is the function of a price assumption and a heuristic that scans the chain for pay-to-pubkey outputs. Both inputs move daily. The number itself is not the news. The news is that the standards track, which was the soft uncertainty in the BIP 360 risk model, has just become a hard one.

What this means for the person holding the key today

Nothing changes at the key level for a person who already holds a hardware wallet with a 24 word seed and a passphrase, and who has never reused an address. Their box closes with secp256k1, their box opens with secp256k1, and the NIST publication does not retroactively rewrite their witness. They do not need to download a new wallet, and they do not need to move coins to a still-closed address. The move they would have made last year is the move they should make next year, for the same reason they should have made it last year. Address hygiene, not algorithm hygiene.

For a person whose coins sit behind a P2PK output, the calculus is not the same. A P2PK output is the chain equivalent of writing a public key on the front of the box. It has been the cat's favourite example for the runway counter story, and it remains so. The October 2026 NIST closure does not bring a quantum computer to the network, and it does not make a secp256k1 discrete logarithm any easier. It does, however, remove the standards-stage objection that some reviewers of BIP 360 had been raising since the Munich workshop in March 2025.

For a person who uses an exchange, the advice is the one CatBitcoin has printed before. The exchange holds the box. The exchange holds the key. The exchange, not the user, decides when the box migrates. A NIST standard does not change the user's recourse. It does not give the user a withdrawal right they did not have, and it does not give the exchange an excuse to delay a withdrawal that was already owed. The proof-of-reserves conversation, which the cat has avoided for unrelated reasons, is the proof-of-reserves conversation, and it predates ML-DSA.

The runway counter, in light of a settled primitive

Runway counter, in the cat's working definition, is the time remaining before a sufficiently capable fault-tolerant quantum computer could open a P2PK lockbox. The counter is not a Bitcoin block height. It is a research and engineering estimate, and it is the kind of estimate that the IonQ 26 day secp256k1 paper read through the box earlier this year. The estimate does not get better when NIST publishes. It gets louder.

What gets sharper is the policy question. A settled primitive is a primitive a regulator can name. A regulator who can name a primitive is a regulator who can write a deadline. A deadline, in turn, is the precondition for the kind of timed covenant that BIP 360 proposes. The cat does not endorse the deadline, and the cat does not endorse the covenant, but the cat notes that the two have a shared assumption, and that assumption now has a name.

For the running total on the runway counter, the cat continues to publish the column. The numbers move. The columns do not. The October 2026 closure of the NIST third round is a column note, not a column replacement.

What the cat is not claiming

The cat is not claiming that ML-DSA will land in Bitcoin. The cat is not claiming that a quantum computer is one funding round away. The cat is not claiming that the runway counter has shortened because NIST published a standard. The cat is not claiming that a watch-only field is a place to paste a seed, that a passphrase is optional, or that an xpub is safe to share. The cat is claiming, in one sentence, that a standards-track closure is a step in a longer process, and that the box, the key, and the address label are three different objects that the longer process will touch at three different speeds.

The longer process has more moving parts than the cat can list in a single column. It has a fork calendar that is not yet a calendar. It has a wallet migration that is not yet a migration. It has a recovery story that the seedless recovery vendors are still arguing about. The October 2026 NIST closure does not settle any of those, and the cat does not pretend that it does.

What the cat will say, and will keep saying, is that the box is still closed, the key still has to come from somewhere the box owner controls, and the watch-only field is still not the place to put it. ML-DSA does not change the spelling of any of those warnings. It does not shorten the warnings. It does, in a small way, sharpen them, and the sharpening is the news.