Axven Bitcoin PQ Lab: ML-DSA measurements and deterministic regtest evidence

[Axven]

Axven Bitcoin PQ Lab — Phase 2 + Phase 3 research results

I have been working on an experimental post-quantum research environment to study engineering questions around a possible future Bitcoin migration.

The work currently consists of two evidence checkpoints:

Phase 2 — ML-DSA-44/65/87 measurements, real Bitcoin Core regtest evidence, Classical AND PQ laboratory authorization, provenance and validation.

Phase 3 — fresh regtest evidence generation, deterministic evidence replay, independent receipt validation and fail-closed tamper testing.

This work is strictly research-only and off-consensus.

Bitcoin Core, Bitcoin consensus and Bitcoin Script were not modified.

Environment

Bitcoin Core: v31.1
Source commit:

Code:

9be056a8a72b624dae9623b2f7bded92c2a21c91

Runtime: WSL2 / x86_64
Python: 3.12.3
cryptography: 48.0.0

Phase 2

Final test suite:

239 / 239 tests passed
0 failures
0 errors
0 skipped

The experiment was bound to a real confirmed Bitcoin regtest transaction.

Observed transaction properties:

- Serialized transaction: 222 bytes
- Weight: 561 WU
- Virtual size: 141 vB
- Confirmations: 1
- Block height: 102

ML-DSA observations

ML-DSA-44
Public key: 1312 B
Signature: 2420 B
Median verify: ~0.279 ms

ML-DSA-65
Public key: 1952 B
Signature: 3309 B
Median verify: ~0.419 ms

ML-DSA-87
Public key: 2592 B
Signature: 4627 B
Median verify: ~0.655 ms

These measurements are laboratory observations only.

They must not be interpreted as Bitcoin transaction or block-space costs because no Bitcoin Script/output/witness representation for ML-DSA has been selected.

No production ML-DSA parameter set has been selected.

Cross-candidate rejection

Six mismatched candidate directions were tested:

ML-DSA-44 -> ML-DSA-65
ML-DSA-44 -> ML-DSA-87
ML-DSA-65 -> ML-DSA-44
ML-DSA-65 -> ML-DSA-87
ML-DSA-87 -> ML-DSA-44
ML-DSA-87 -> ML-DSA-65

6/6 tested mismatches were rejected.

This is limited to these tested cases and is not a general cryptographic security proof.

Classical AND PQ laboratory experiment

The experimental authorization model evaluates:

Code:

Classical authorization AND PQ authorization

The classical side is an external laboratory boolean oracle.

It is not Bitcoin Core authorization and is not being proposed as a Bitcoin consensus rule.

Phase 2 canonical evidence SHA-256

Code:

d3fdb272903fb6112db18ec6ad044fbe268937a3302da626914e540cdf863540

The repository validator independently reproduced the same canonical digest.

Phase 3 — deterministic evidence replay

Phase 3 is a separate reproducibility checkpoint.

It does not claim to reproduce the historical Phase 2 artifact. Instead, a fresh Bitcoin Core v31.1 regtest E2E artifact was generated and validated before deterministic replay.

Targeted regression gate:

15 / 15 tests passed

Phase 3 replay/receipt: 8/8
Phase 2 validator regression: 7/7

Fresh canonical E2E evidence SHA-256:

Code:

cf5e2c938e3d21c473bacabedc19c69d208310c937ccf4782ba5c77dffda1a2d

Fresh e2e.json byte-level SHA-256:

Code:

859c0e80a37d1af579261ac6c7aa5c52b54fe23ae184a63f9aa1ad52110c345f

Deterministic replay

The validated evidence was replayed twice.

Both replay outputs were byte-identical.

Replay output SHA-256:

Code:

c00db3f7e04d19dce132dbe440e185d4a1ccabd434b07854bb1252e6ecb617b5

REPLAY BYTE DETERMINISM = PASS

Independent receipt validation

The independent receipt validator accepted the intact receipt and returned:

Code:

f636897379337e61ebbc6c596fb3fa95bb9b1ae320b4dfc18ea0dd72dbd9f56c

Fail-closed tamper test

A copy of the accepted receipt was modified by replacing its bound input evidence digest.

The independent validator rejected it with:

Code:

ValueError: replay receipt digest mismatch

Exit status: 1

What this research does NOT claim

- Bitcoin is not claimed to be quantum-safe.
- Bitcoin Core does not support or verify ML-DSA through this experiment.
- ML-DSA has not been integrated into Bitcoin Script.
- Bitcoin consensus has not been changed.
- No opcode/output/witness semantics have been introduced.
- No production ML-DSA parameter set has been selected.
- No mainnet activation or migration policy has been selected.

Questions / feedback

I would particularly appreciate technical criticism around:

1. What evidence should be collected before attempting any Script-level prototype?
2. What output/witness semantics would be worth experimentally evaluating?
3. How should classical + PQ authorization be studied during a possible migration period?
4. How should exposed versus non-exposed legacy outputs be considered?
5. What transaction/block-space measurements would be most useful?
6. What failure modes should a long migration experiment model?

Repository:

https://github.com/AxvenLabs/axven-bitcoin-pq-lab

Phase 2 evidence:

PHASE2_FINAL_RESULTS.md

Phase 3 evidence:

PHASE3_LIVE_REPLAY_RESULTS.md

[Danish Ali]

The most notable takeaway from this is how small the execution time is relative to the signature/keysize. Especially relative to block-space concerns, these are extremely small numbers, and this is not even accounting for the rest of the transaction.

Which scheme?

Given how small the execution times are (which is good!), the "which scheme" question will mostly come down to key/signature size, which means that hash-based schemes (including one-time schemes like SHRINCS) look attractive. The drawback of one-time schemes is the name. But, I think it may make sense to treat them as a "break glass" option, not the primary option. This might make sense as part of an OR-of-branches scheme, for example, an output which is "spendable by classical key today, OR by PQ key after some condition," or even just "OR by SHRINCS key," the latter being sort of like Taproot's scriptpath spend (small output/address; large spend).

I don't think this is out of scope for your work, but you could consider measuring the size of transactions which commit to a PQ pubkey in the output, and reveal it at spend-time (something like Taproot's scriptpath spend). Such transactions would have the benefit of not bloating addresses/outputs with PQ pubkeys.

Size of tx?

Your example tx is only 222 bytes / 141 vB, and does not account for the size of a PQ pub and sig. A single ML-DSA-44 pub+sig is 3732 bytes, which is about 17 times larger than your example tx. And, this would go into the witness, so, assuming the ~4x discount for witness data, a single ML-DSA-44 sig/pub is going to be around 900-1000 weight units (WU). That's not counting the rest of the tx, but, that's still larger than most modern legacy txes. ML-DSA-87 would be ~2x this. This is assuming we're going with "ML-DSA in a witness the same way ECDSA/Schnorr sit today," which may not make sense given the sizes involved.

I don't think it's a problem that you haven't tested transactions using PQ sigs, especially given the above, but it could be interesting to explore transactions which reveal PQ data at spend-time. It's unclear whether it makes sense to replace ECDSA/Schnorr directly, given the sizes involved, but, it's clear that a commitment+reveal design makes sense. This might even be useful for classical sigs, for example, reveal Schnorr pubkey at spend-time instead of committing to it in the address.

Avoiding making claims?

Yes, it's good to avoid making claims that go beyond what has been tested, especially when there isn't consensus on parameters/etc. Not a concern.

The "Classical AND PQ" oracle sounds like Dryja's PQ recovery design that's been discussed here. One thing to consider is whether AND is the right option; it's very expensive given the size of PQ sigs (effectively paying for two sigs to spend). Might be interesting to explore this as a more complex ScriptPubkey that spends via an OR-of-branches, for example, "spendable by classical key today, OR by PQ key after some condition," etc. This way you get the optionality/benefit of PQ without paying for both sigs every time you spend.