Notes on adding a post-quantum signature path to a Bitcoin-derived protocol

[jwlcore]

This is an experimental effort based on a Bitcoin-derived codebase.

The goal is not to replace Bitcoin or alter its existing cryptographic rules,
but to introduce an additional post-quantum signature verification path at the
consensus level.

The approach is modular:

- Legacy ECDSA/secp256k1 remains untouched and continues to validate historical
  data and legacy outputs.
- A new script opcode introduces post-quantum signature verification (currently
  Dilithium-based) as a separate consensus path.
- The scriptPubKey explicitly determines which verification path is used, so
  there is no ambiguity for nodes.

Post-quantum signatures are intended to become the default for newly created
outputs over time, while legacy cryptography remains only for compatibility.
No hard cutoff, no forced migration.

At the current stage:
- The post-quantum opcode is integrated into the script engine.
- Deterministic consensus tests are passing.
- There is no mining, no release, and no economic activity yet.

This post is not an announcement and not a proposal for deployment.
It is shared to explain the design and to invite technical discussion
around consensus safety, script semantics, and long-term maintainability.

[jwlcore]

For clarity, here is a screenshot of the current build and test output.

The post-quantum opcode is compiled as part of the codebase and exercised
through deterministic script-level tests.

No claims beyond that — just showing the current state of the implementation.

https://ibb.co/MDWqFPjw
https://ibb.co/1tWRCwjB

We have completed the most important consensus part for MVP PQCHECKSIG in pre-tapscript:
EvalPQChecksigPreTapscript(...) it already exists and does:
FindAndDelete for BASE
empty-sig → success=false
calls checker.CheckPQSignature(...)
NULLFAIL does not fix specific errors
  GenericTransactionSignatureChecker<T>::CheckPQSignature(...) now:
gives SCRIPT_ERR_PUBKEYTYPE if the pubkey is the wrong size
  gives SCRIPT_ERR_SIG_DER if the sig is the wrong size
  considers SignatureHash(...) consensus
calls PQ_Verify(...)

And the tests confirmed it: “6 test cases passed”

[BattleDog]

Keeping legacy secp256k1 untouched, and making the scriptPubKey unambiguously pick the verification path does indeed avoid whole class of consensus footguns and node confusion, that's good.

The stuff I'd be paranoid about next is the "how do we stop this from becoming a cheap DoS primitive" path. Dilithium sigs/keys are chunky and verification isn't free, so you'll want really strict size/format checks before you even touch PQ_Verify, plus clear limits in consensus/policy so someone can't spam borderline-valid blobs that are expensive to reject.

Just a small insight from me, hopefully to keep you going on the right path 

[jwlcore]

Keeping legacy secp256k1 untouched, and making the scriptPubKey unambiguously pick the verification path does indeed avoid whole class of consensus footguns and node confusion, that's good.

The stuff I'd be paranoid about next is the "how do we stop this from becoming a cheap DoS primitive" path. Dilithium sigs/keys are chunky and verification isn't free, so you'll want really strict size/format checks before you even touch PQ_Verify, plus clear limits in consensus/policy so someone can't spam borderline-valid blobs that are expensive to reject.

Just a small insight from me, hopefully to keep you going on the right path 

Thanks that’s exactly the class of issues I’m focusing on next.

The current goal was to make the verification path explicit and deterministic first, without touching legacy secp256k1, precisely to avoid cross-path confusion.

DoS surface from large PQ objects is well understood. The plan is to enforce strict size and format validation before PQ_Verify is ever reached, so malformed or borderline inputs are rejected in constant time.

In addition, explicit limits are being introduced at both consensus and policy level (max sig size, max pubkey size, script element limits), so verification cost is bounded and predictable.

Optimizing representation and moving heavy data out of the base path is intentionally deferred to a dedicated witness-style upgrade, once the base PQ consensus rules are fully hardened.

Appreciate the insight this is exactly the direction the design is heading.

[MusicLand]

dilithium signatures are huge compared to ecdsa though right, i wonder how this would affect the fees and the block size if everyone starts using them suddenly

[jwlcore]

dilithium signatures are huge compared to ecdsa though right, i wonder how this would affect the fees and the block size if everyone starts using them suddenly

Yes, Dilithium signatures are significantly larger than ECDSA.

In the current base-script integration this naturally means higher absolute fees, since fees are still calculated per byte and block space is limited. This is intentional for the initial phase, as it makes the cost explicit and discourages sudden mass usage before the system is fully optimized.

This is not the final design. A witness-style upgrade is planned to move heavy signature data out of the base transaction structure and introduce proper weight-based accounting, similar to how SegWit addressed the same issue for ECDSA.

The current focus is correctness and deterministic consensus. Size and fee efficiency are treated as a separate, subsequent step.