PQ txid malleability is the next box nobody is packing

PQ-safe transaction IDs and the quantum shield debate

Updated 20 October 2026

That is a calendar collision between two unfinished tracks. It is not a vulnerability in either one on its own.

Why a PQ signature makes a txid squishy again

Bitcoin transaction identifiers are the SHA-256 double hash of the transaction's serialised form. A signature sits in the witness, outside the script, and SegWit gave us the property that mutating a signature does not change the txid. That property is what made payment batching, Child Pays For Parent, and Lightning channel updates work without breaking the mempool.

Post-quantum signature schemes are big. The ML-DSA lattice finalists produce signatures that range from 2420 bytes for ML-DSA-44 up to 4627 bytes for ML-DSA-87, and SPHINCS+ signatures run from 7856 bytes for SPHINCS+-SHA2-128s to 49216 bytes for the SHA2-192s variant. Every byte in that witness is, in principle, a knob an attacker can turn to mutate a witness without invalidating the spend. The txid is supposed to be immune to that, but only if the wallet serialises the witness deterministically.

Deterministic signing with a hash-based scheme like SPHINCS+ is feasible because the signature is a function of the secret key, the message, and an optional random nonce. Strip the random nonce, and the same key signing the same message produces byte-identical output every time. ML-DSA in its FIPS 204 final form added an optional deterministic mode for exactly this reason. The 2024 finalisation of FIPS 204 made deterministic ML-DSA a parameter, not a hope, and the drafters put it in the standard because Bitcoin, TLS, and a dozen other protocols asked for it.

Deterministic signing closes the easy mutation vectors. It does not close the case where two parties collaborate on a transaction and one of them later rewrites their witness. It also does not close third-party malleability introduced by a relayer that rewrites a tapleaf or a sequence value in the non-witness portion of the transaction. That second class of mutations was the reason BIP 62 and BIP 146 existed, and it is the reason a fresh round of txid discussion has opened on the bitcoin-dev mailing list this quarter.

What changes with PQ is the size of the witness, and therefore the size of the surface a mutator can scratch. A 4627-byte signature in a 5000-byte witness gives an attacker roughly nine times more bits to wiggle than a 72-byte ECDSA signature in a 110-byte witness. The probability of an accidental collision stays negligible. The probability of a deliberate collision against a target txid stops being negligible if the attacker can grind across billions of candidate witnesses per second on commodity hardware.

What BIP 360 actually says about malleability, and what it does not

The BIP 360 proposal, drafted by Hunter Beast and collaborators, focuses on three things: a new address format, a phased migration of coin movement, and a soft fork that invalidates legacy spends once the quantum shield window closes. The address format is bech32m-encoded and uses a hash of a PQ public key as the destination. The migration phase freezes legacy UTXOs into a witness that proves ownership through a hash preimage reveal, a one-time mechanism that exposes the public key to the chain. The freeze phase burns any UTXO whose owner has not migrated by the deadline.

Malleability is not in the BIP. Not in the address section, not in the migration section, not in the freeze section. The draft explicitly defers third-party malleability to a separate proposal, citing the same reasoning that pushed SegWit ahead of a full fix: the upgrade is large enough already, and folding malleability in would have made consensus review intractable.

This is the calendar problem. The BIP 360 reference timetable sets a quantum shield activation at block height target late 2027, with the freeze to follow after a multi-year warning window. A separate malleability fix that touches witness serialisation, sighash, or both, has been sketched in two competing proposals since 2023, and neither has reached the point of a BIP number. The first proposal suggests hashing the witness into the txid directly, paying the cost in cache and bandwidth. The second proposal suggests a per-input commitment that the witness has not been mutated, paid for by a small witness field at spend time. Neither has been merged into the BIP 360 workstream.

The collision, then, is this. A wallet that migrates to a PQ address in 2028 will produce transactions whose txids are not as squishy as they were in 2014, but are not as firm as they were in 2024 either. A miner or a relayer with a sufficiently large witness to grind on can rewrite the txid under a sender's feet. Lightning channel closes, coinjoins, and atomic swaps that rely on txid pinning all face the same risk they faced before SegWit, only with a witness an order of magnitude larger.

The shield phase as a malleability deadline

Bitcoin Core's quantum working group circulated a draft schedule in September 2026 that lines up BIP 360's reference activation with a warning that the freeze date is conditional on PQ signature review completing first. The review is not a formality. ML-DSA-44 and ML-DSA-65 are the two parameter sets most often floated for Bitcoin, and they differ in signature size, public key size, and signing time. ML-DSA-44 has 1312-byte public keys and 2420-byte signatures. ML-DSA-65 has 1952-byte public keys and 3309-byte signatures. The third finalist, ML-DSA-87, sits at 2592-byte public keys and 4627-byte signatures, and is the only one with a security claim above NIST level 3.

The choice between these parameter sets is the choice between a smaller witness, a larger witness, and a quantum security margin. The malleability surface scales with witness size. A wallet running ML-DSA-87 inherits roughly 1.9 times the grinding surface of a wallet running ML-DSA-44. A wallet running SPHINCS+-SHA2-128s inherits roughly 3.2 times the grinding surface of ML-DSA-44 and pays for it in signing time that runs into hundreds of milliseconds on consumer hardware.

This is not a problem BIP 360 can solve by itself. The malleability fix has to land before or alongside the quantum shield activation, and the calendar the working group has published does not have a malleability fix on it. The window between BIP 360 activation and the freeze is the period during which every migrated UTXO is, in principle, grindable for txid collisions. For a high-value consolidation transaction, a successful grind gives an attacker the ability to front-run the spend with a double-spend that reuses the same inputs but lands in a different block.

The community has known about this for at least two years. The reason it has not been fixed is that any malleability fix is a soft fork that touches every full node, and the quantum soft fork is also a soft fork that touches every full node. Running them in sequence means a longer review window. Running them together means a single, larger soft fork that some maintainers have argued is too large to review in a single cycle. The September 2026 draft schedule splits the difference: BIP 360 ships first, a malleability fix ships in a follow-up release, and the freeze date is conditional on the follow-up reaching activation.

What a wallet can do today, and what it cannot

Wallet authors shipping BIP 360 support in 2026 and 2027 have to make a decision about deterministic signing, and the decision is not free. Deterministic ML-DSA removes the easy mutation vector but costs roughly 10 to 15 percent of signing throughput on consumer hardware, according to benchmarks circulated in the working group's September 2026 draft. Deterministic SPHINCS+ is the default because SPHINCS+ is already deterministic in its standard form, but SPHINCS+ signing is slow enough that the deterministic mode is a rounding error on top of an already long signing time.

Wallet authors also have to make a decision about witness serialisation. SegWit's witness format places a varint length prefix in front of each witness element, and the length prefix is part of what gets hashed for the txid. A wallet that serialises a witness in different orders across two attempts at the same transaction will produce two different txids. Most modern wallets agree on a canonical order, and the order is part of the Bitcoin Core consensus rules. The risk is that a PQ wallet implementation that has not been audited produces non-canonical witnesses under load, and a relayer notices before the wallet does.

The pragmatic answer for a wallet author shipping in 2027 is to commit to a witness serialisation policy, run it through a third-party fuzzer, and document it. The defensive answer is to refuse to relay transactions with non-canonical witnesses, and to log every witness mutation observed at the wallet layer. Neither answer is consensus-level. Both are mitigations, and the gap between mitigations and a fix is the gap that BIP 360 leaves open.

The risk surface for a migrated user

A user who migrates a UTXO to a BIP 360 address in 2028 is, for the duration of the shield window, exposing themselves to a class of risk that legacy users do not face. Legacy users spend through P2PKH or P2WPKH, and their witnesses are small enough that grinding for a txid collision is computationally infeasible against a target. Migrated users spend through a PQ address, and their witnesses are large enough that grinding for a txid collision is computationally feasible if the attacker controls enough CPU cycles.

The risk is bounded. A successful grind lets an attacker rewrite a txid, not the underlying spend. The attacker cannot redirect funds, cannot change the destination address, and cannot increase the fee past the sender's signed value. What the attacker can do is interfere with downstream protocols that depend on the txid: a coinjoin coordinator that uses txid as a coordination key, a Lightning channel close that depends on a specific txid landing in a specific block, a sidechain peg that uses a txid as a burn proof.

For a hodler with a single-sig wallet migrating a long-term vault, the risk is negligible. The vault produces one transaction per migration, and the cost of a txid collision against a single transaction is not worth the attacker's time. For a merchant, an exchange, or a Lightning operator running high transaction volumes, the risk scales with volume, and the mitigations are operational rather than cryptographic. Transaction acceleration through package relay, manual rebroadcasting, and a willingness to pay higher fees in the face of a mempool attack are all that a high-volume operator can do until the malleability fix ships.

Where this leaves BIP 360 in late 2026

BIP 360 in its current form is a quantum migration proposal that does not contain a malleability fix and does not reference a malleability fix from another BIP. The September 2026 working group draft acknowledges the gap, lists the two competing malleability proposals by name, and notes that the freeze date is conditional on the malleability fix reaching activation. None of this is hidden. It is in the draft, and the draft has been public since the third week of September.

What is hidden is the political question of whether the malleability fix and the quantum soft fork should be merged. The maintainers who argue for merging point to a single review window, a single release train, and a single set of test vectors. The maintainers who argue against merging point to a single soft fork that touches witness serialisation, sighash, address format, and UTXO semantics in the same activation, and the cognitive load of reviewing all four at once. Both positions are reasonable. Neither has won.

For a user, the practical conclusion is that a migration planned for 2028 or 2029 should be reviewed against the assumption that txid malleability will be a live concern during the shield window, and that a high-volume operator should plan for an additional mitigation layer until a consensus fix lands. For a developer, the practical conclusion is that a wallet implementation in 2026 and 2027 has to commit to deterministic signing, canonical witness serialisation, and a documented mutation detection policy, and that none of these are substitutes for a consensus fix.

Sources and further reading

BIP 360 draft, September 2026 revision, on the bitcoin-dev repository. The draft includes the warning that the freeze date is conditional on the malleability fix, and it is the canonical reference for the calendar described in this post.

FIPS 204 final, August 2024. The standard finalises ML-DSA in three parameter sets, and the optional deterministic mode is what makes BIP 360 wallet implementations tractable on consumer hardware.

SPHINCS+ specification, NIST SP 800-228 draft, 2024. The parameter sets quoted in this post are the SHA2 variants at 128-bit, 192-bit, and 256-bit security levels.

The malleability fix proposals, on the bitcoin-dev mailing list under the threads titled 'Witness-stripped txid' and 'Per-input witness commitment', both running since 2023. Neither has reached a BIP number as of October 2026.