Ran into this while bringing up a dev node on post_quantum to test wallet-side SLH-DSA signing. Took me a while to spot, so writing it down in case it saves someone the detour.
Symptom
Creating/funding a post-quantum account fails on-chain:
(coin.transfer-create "k:f05b0deb..." "q:8027c8d5..." (read-keyset "ks") 5.0)
-> failure: Invalid keyset format. Check that keys have the right length and signature scheme.
Same for an x: account (all-PQ multisig keyset, keys-2). The tx mines, the keyset is what gets rejected. The same keyset is fine in the interpreter, so it only shows up with a full node.
Cause
The code is there, it just isn't in the build. cabal.project pins pact-5 at cbf0f14 (Jan 3), and slhKeyFormat landed two days later, in 15d86e13 ("Enable reading SLH keysets").
Pinned pact-5, pact/Pact/Core/Guards.hs:
isValidKeyFormat :: PublicKeyText -> Bool
isValidKeyFormat k = any ($ k) allKeyFormats -- ed25519 + webauthn only
Later on the same branch:
isValidKeyFormat disableSlh k = any ($ k) formats
where formats | disableSlh = [ed25519HexFormat, webAuthnFormat]
| otherwise = [ed25519HexFormat, slhKeyFormat, webAuthnFormat]FlagDisableSlhDsaSignatures never gets set by chainweb (defaults in Chainweb/Pact5/TransactionExec.hs are FlagDisableRuntimeRTC, FlagEnforceKeyFormats, FlagAllowReadInLocal, FlagRequireKeysetNs), so the q format is just absent.
What fixed it for me
Bumping the pin to 15a22e1b (Feb 26), which is the newest commit that has slhKeyFormat and is still before the crypton change. Freeze untouched, no dependency changes, only pact-tng and chainweb rebuild.
On a dev node (--chainweb-version development --disable-pow --enable-node-mining):
|
before |
after |
transfer-create to a q: (single key) |
Invalid keyset format |
success, balance on chain |
transfer-create to an x: (2-of-2, all-PQ) |
Invalid keyset format |
success, balance on chain |
spend from a q: (SLH-DSA sig) |
rejected at /send |
unchanged, still rejected |
A successful one after the bump:
requestKey PwklwOu2dzLu5xYqiXLhwAYaF2QOVYcY0KoMqBHwH1E
status success | gas 212 | block 613
coin.details -> guard { pred: keys-all, keys: ["q9862b767..."] }
Log stayed clean and the node kept mining on the existing db, so no fresh chain needed.
Don't bump straight to the branch HEAD
00b9b8e doesn't build. 7feeab02 ("Update crypton, and replace memory by ram") moves pact-tng to crypton >=1.1.2. Getting a plan out of that needs a newer index-state plus relaxing crypton, crypto-token, tls-session-manager, tls, hpke, the crypton-x509* / crypton-asn1* family, http-client-tls, and the pandoc cluster that comes in through lib:pact-repl. And once it does resolve, pact-4.13.2 and merkle-log fail to compile against crypton 1.1.4 on Data.ByteArray (getRandomBytes n = BA.pack <$> replicateM n arbitrary).
Still open after this
Spending from a q: is untouched by the bump. /send still parses the Command with pact-4, whose PPKScheme is ED25519 | WebAuthn:
reading JSON for transaction failed:
Error in $.signers[0].scheme: Unsupported PPKScheme: "SLH-DSA-SHA2-128s"
which matches the -- TODO: convert to Pact 5 in Chainweb/Pact/RestAPI/Server.hs.
I know the branch still needs a proper integration with main, so I haven't opened a PR for the pin bump. Happy to send it if it's useful in the meantime.
Ran into this while bringing up a dev node on
post_quantumto test wallet-side SLH-DSA signing. Took me a while to spot, so writing it down in case it saves someone the detour.Symptom
Creating/funding a post-quantum account fails on-chain:
Same for an
x:account (all-PQ multisig keyset,keys-2). The tx mines, the keyset is what gets rejected. The same keyset is fine in the interpreter, so it only shows up with a full node.Cause
The code is there, it just isn't in the build.
cabal.projectpins pact-5 atcbf0f14(Jan 3), andslhKeyFormatlanded two days later, in15d86e13("Enable reading SLH keysets").Pinned pact-5,
pact/Pact/Core/Guards.hs:Later on the same branch:
FlagDisableSlhDsaSignaturesnever gets set by chainweb (defaults inChainweb/Pact5/TransactionExec.hsareFlagDisableRuntimeRTC,FlagEnforceKeyFormats,FlagAllowReadInLocal,FlagRequireKeysetNs), so theqformat is just absent.What fixed it for me
Bumping the pin to
15a22e1b(Feb 26), which is the newest commit that hasslhKeyFormatand is still before the crypton change. Freeze untouched, no dependency changes, only pact-tng and chainweb rebuild.On a dev node (
--chainweb-version development --disable-pow --enable-node-mining):transfer-createto aq:(single key)Invalid keyset formattransfer-createto anx:(2-of-2, all-PQ)Invalid keyset formatq:(SLH-DSA sig)/sendA successful one after the bump:
Log stayed clean and the node kept mining on the existing db, so no fresh chain needed.
Don't bump straight to the branch HEAD
00b9b8edoesn't build.7feeab02("Update crypton, and replace memory by ram") moves pact-tng tocrypton >=1.1.2. Getting a plan out of that needs a newerindex-stateplus relaxingcrypton,crypto-token,tls-session-manager,tls,hpke, thecrypton-x509*/crypton-asn1*family,http-client-tls, and thepandoccluster that comes in throughlib:pact-repl. And once it does resolve,pact-4.13.2andmerkle-logfail to compile against crypton 1.1.4 onData.ByteArray(getRandomBytes n = BA.pack <$> replicateM n arbitrary).Still open after this
Spending from a
q:is untouched by the bump./sendstill parses the Command with pact-4, whosePPKSchemeisED25519 | WebAuthn:which matches the
-- TODO: convert to Pact 5inChainweb/Pact/RestAPI/Server.hs.I know the branch still needs a proper integration with main, so I haven't opened a PR for the pin bump. Happy to send it if it's useful in the meantime.