DRAFT: Post Quantum signatures

[CryptoPascal31]

Push Post-quantum signatures to Chainweb

[dnns-es]

Tested post_quantum_2 end to end on a private devnet. Short version: it builds clean and funding a q: account works, but spending from one is still blocked at /send.

Build. cabal build exe:chainweb-node -j6 succeeded first try, no patches, GHC 9.10.2 (chainweb-node-3.2.1 revision e80f340-post_quantum_2). The pact-5 pin f8c98346 carries slhKeyFormat, so the keyset problem from #39 is gone.

Setup. chainweb-version development, --disable-pow, fresh database, wallet signing SLH-DSA-SHA2-128s per KIP-0041 (HashSLH-DSA, context CHAINWEB, blake2b-256 OID) with an independent implementation (@noble/post-quantum).

1. Creating and funding a q: account — works. coin.transfer-create from the miner to q:dd7a9db5cbd413666f6f2b0b1a113d8db83e7350cf2d69f7ac7ce998983e25ea with a q-prefixed keyset was mined at block 9, balance 1.0. This used to fail with Invalid keyset format.

2. Spending from it — rejected before anything is verified. Same account, coin.transfer signed with SLH-DSA (10475-char unpadded base64url signature):

POST .../chain/0/pact/api/v1/send  ->  400
reading JSON for transaction failed: Error in $.signers[0].scheme:
Unsupported PPKScheme: "SLH-DSA-SHA2-128s"

3. Control. The exact same command with only the scheme name changed to "ED25519" gets through the parser and dies later, where it should:

Invalid transaction sigs: The signature at position 0 is invalid:
invalid ed25519 signature.

So the wall is the deserialization step, not the signature path. sendHandler in Chainweb/Pact/RestAPI/Server.hs still decodes the batch with pact-4 types (its -- TODO: convert to Pact 5), and the pinned pact-4 (kda-community/pact@ef859d8) still has data PPKScheme = ED25519 | WebAuthn, so any SLH-DSA signer dies at the door. Everything downstream is already pact-5 and, from what I measured on the old branch with a 3-line local patch to the pact-4 parser, works: the transaction went through mempool, gas buying, signature validation and execution and was mined, and the same transaction with one bit flipped in the signature was rejected. Same finding as #41.

Two smaller notes from reading the diff:

• test/lib/Chainweb/Test/Pact5/CmdBuilder.hs has _ -> error "SLH DSA not implemented here for now", so no test can build an SLH-DSA command yet. I have deterministic Chainweb-framing vectors (valid + must-reject + base64url padding cases) checked against verifySig, happy to contribute them wherever they are useful.
• In RecapDevelopment.hs, next to your -- TODO Something wrong here: the rule reads (ForkNever, post33GasModel) Above ..., and with ForkNever that entry can never be selected, so recap devnet stays on post31GasModel.

Also, kda-community/pact-5#23 still applies to the new pin: decodeBase64UrlUnpadded is B64URL.decode, which accepts a trailing = on signatures.

Happy to re-run any of this. The devnet, the wallet and the cross-verification harness are set up, so testing your integration is cheap on my side.