Thoughts on integrating a post-quantum signature option into a Bitcoin-based protocol

So, I'm working on this experimental project that builds off a Bitcoin codebase. Just to be clear, this isn't about changing Bitcoin or its cryptographic rules. The idea is to add a new way to verify signatures using post-quantum methods at the consensus level. Here's the deal: - The original ECDSA/secp256k1 stays as is, still validating old data and legacy outputs. - We’re adding a new script opcode that allows for post-quantum signature verification, which is based on Dilithium, as a separate option for consensus. - The scriptPubKey will clearly indicate which verification method to use, eliminating any confusion for nodes. The plan is that over time, post-quantum signatures will become the go-to for new outputs, while the old cryptography will just serve for compatibility. There won't be a hard cutoff or any forced changes. Right now: - The post-quantum opcode is in the script engine. - We’ve got deterministic consensus tests working. - No mining or economic activity is happening yet, and there’s no release. This isn't an announcement or a deployment proposal. I'm sharing this to explain the design and hopefully kick off a conversation about consensus safety, script semantics, and how to maintain this long-term.

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”

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

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.

update. Stage 1 of the roadmap is now complete: post-quantum signature verification as a consensus rule (pre-tapscript). Over the last step we also strengthened it with explicit anti-DoS guarantees, backed by tests. At this point, the following is implemented and fixed. PQ opcodes are part of consensus (pre-witness). OP_PQCHECKSIG / OP_PQCHECKSIGADD follow the same semantic model as OP_CHECKSIG. Legacy secp256k1 remains untouched. The verification path is selected unambiguously by scriptPubKey, so there is no ambiguity or soft confusion. PQ verification uses a separate pipeline. There is no reuse of ECDSA logic. The signature hash is computed via the consensus SignatureHash(), not from raw scriptCode. PQ verification is executed only after all cheap checks pass. ScriptError semantics are now strict and stable. We intentionally fixed the error contract to avoid gray areas:  SCRIPT_ERR_PUBKEYTYPE (28) — invalid PQ public key size  SCRIPT_ERR_SIG_DER (23) — invalid / zero / malformed signature body  SCRIPT_ERR_SIG_HASHTYPE (22) — invalid or missing sighash type This contract is enforced and tested. Cheap-reject before expensive verify (anti-DoS). The evaluation order is strictly:  1. pubkey size check  2. signature size check  3. zero-blob detection  4. sighash type validation  5. only then → SignatureHash()  6. only then → PQ_Verify() This guarantees that malformed or adversarial inputs are rejected before any expensive cryptography is touched. Explicit anti-DoS test coverage is in place. A dedicated test suite proves the ordering above:  - solver / policy tests  - mempool + submitblock rejection tests  - a fuzz-like audit with 3000 assertions over:  - valid-size but garbage inputs  - boundary sizes  - zero pubkeys / zero signatures  - bad hashtypes All of these cases are rejected cheaply and deterministically. Current test status:  - all build_fulltests are green  - PQ consensus tests, solver policy tests, and mempool/submitblock tests all pass (Screenshots attached.) https://ibb.co/hFy4ZRr2 https://ibb.co/H8fpTv7 Why this matters. This closes the most dangerous class of issues for PQ integration:  no expensive verification on junk inputs  no mempool or submitblock bypass  no cache shortcuts  no reliance on policy-only behavior At this point, PQ signatures are real consensus objects, not experimental scripts. What comes next. The next steps are intentionally small and focused:  1. a final cheap-reject audit (assert-level verification that SignatureHash() is never called on invalid inputs)  2. additional edge-case tests around size and format limits No claims beyond that - just documenting the current state of the implementation. Feedback and review are welcome.

Small status update. The node is now mining blocks with PQ-enabled consensus rules active. Coinbase outputs are being created under the post-quantum script path. Attached screenshot shows: - mined coinbase transaction - block height and confirmations - current total coinbase amount No claims beyond this. Spendability and size analysis will be shown after the coinbase reaches maturity and is spent under PQ rules. Posting this only as a factual progress update. https://ibb.co/tpPrJtKx

Update (testing): PQ spend mined successfully Quick status update with a concrete runtime proof (screenshots attached). I’ve now produced and mined a transaction spending a PQ output where the locking script uses a Dilithium verification path (… OP_EQUALVERIFY OP_CHECKSIGDILITHIUM). Evidence shown in the screenshots: the scriptPubKey.asm of the spent output (explicit PQ verification path in script) the transaction entering the mempool and then being mined block/height + confirmations after mining This is still in the “engineering proof” phase: demonstrating that the PQ script path is usable end-to-end (create → broadcast → mine → confirm), before moving on to the next stage. If anyone wants specific additional diagnostics (e.g. size breakdown, policy flags, script execution path), tell me what you’d like to see and I’ll capture it. https://ibb.co/d4FrLR5c https://ibb.co/5hbWrqQK https://ibb.co/YTKCyrMZ

Mining is running stable. Blocks are being found sequentially without stalls or reorgs. All mined blocks use post-quantum coinbase outputs (Dilithium / PQ) by default - no legacy signatures involved in coinbase creation. This confirms:  1. end-to-end PQ path works in practice,  2. block production is stable,  3. miners do not need any special setup beyond the current client. More testing and hardening continues. https://ibb.co/vx89BV2n