XMSS key management: Generate, Sign, HaveKey, GetLeafIndex, GetXMSSKeys

SignXMSS(), HaveXMSSKey(), GetXMSSPubKey() di SigningProvider. CreateXMSSSig() di sign.cpp

CheckXMSSSignature() di BaseSignatureChecker. SignTransactionXMSS() di wallet.cpp

xmss_signer.cpp/h, xmss_address.cpp, xmss_keystore.cpp, rpc/xmss.cpp ditambahkan ke build

6/6 tests passed: keygen, sign/verify, wrong key, stateful signing, sig size

XMSS-SHA2_10_256 key pair. Private key disimpan di qnt_genesis_key.txt

Hash: 5322eeb6160377b16f97e65fd0f67e06db246fe8072e8429215ad16644a6a7bb

10+ blocks mined. Address prefix: qnr. Port: 29333

Base58Check(0x60 || RIPEMD160(SHA256(xmss_pubkey64))). Mainnet prefix 'q'

CXMSSKeyStore: import, export, sign, serialization

getnewxmssaddress, listxmsskeys, getxmssaddressinfo, sendtoxmssaddress

XMSS key per block, pubkey di coinbase OP_RETURN, signature di scriptSig, re-verify PoW setelah sig insertion

SaveState/LoadState/HasExhaustedKeys di CXMSSSigner. WriteXmssState/ReadXmssState di WalletBatch. State di-load saat wallet open, di-save setelah commit transaction. Anti-reuse protection untuk XMSS stateful signatures.

Review key generation, state persistence, signing flow, script engine, wallet keystore, transaction validation

Key exhausted check di Sign(), minimum sig length di interpreter

AUDIT.md written. 2 MEDIUM + 3 LOW findings. No CRITICAL/HIGH. Overall PASS.

Project overview, build guide, quick start, architecture diagram

RPC API reference, XMSS wallet guide, mining guide, testnet guide

Timestamp 1781545300 (15/Jun/2026). Message: "Assentian-PQE Genesis 15/Jun/2026 - NIST SP 800-208 XMSS - Quantum Era Begins"

Resolved duplicate seed definitions (chainparamsseeds.h vs qnt_seeds.h), UniValue API mismatch (push_kv → pushKV), RescanFromTime signature, missing CWallet::AddXMSSKeyToKeystore / GetXMSSPubKey implementations

6 consecutive blocks mined on regtest, all with valid XMSS signature in coinbase witness + 64-byte pubkey in OP_RETURN. CheckPoUW() consensus enforcement confirmed — pouw_enabled: true throughout, zero rejected blocks

BSL-1.1 license added (→ GPL-2.0 in 2030). Whitepaper fixed: license MIT→BSL-1.1, P2P port 8333→9333, magic bytes QNTF→QUAN, halving 2,100,000→210,000 blocks

Dashboard, mining page, explorer, whitepaper.html, and /api/status all verified returning HTTP 200 via nginx reverse proxy. bitcoind + explorer running as systemd services with auto-restart

Migrated from regtest to testnet using the official 15/Jun/2026 genesis block. 6 consecutive PoUW blocks mined, ~2.5-3s per block (XMSS keygen + sign)

Confirmed each block generates a fresh, single-use XMSS key (not reused across the 1024-signature capacity). Noted as a known design tradeoff: simpler and avoids index-reuse risk, but discards 1023 of 1024 available signatures per key and adds ~2-3s per block for keygen

Method was referenced by exportxmsskey RPC but never declared or implemented, causing a linker error. Implemented as a lookup into the in-memory xmss_keys map, returning the serialized secret key

importxmsskey and exportxmsskey were implemented but never added to the wallet RPC command table, so they returned "Method not found" despite compiling successfully

getnewxmssaddress and exportxmsskey tested live on testnet: address generated, key exported with full XMSS secret key structure (OID, index, seed, WOTS chains) returned correctly

CheckPoUW() returned true unconditionally whenever nPoUWStartHeight > 0 (the production setting). The promised height-gated check in ContextualCheckBlock did not exist. Every prior block had a valid signature only because our own miner attached one out of habit — consensus never required it.

Added nHeight and fCheckPOW parameters through CheckPoUW → ContextualCheckBlock, so the signature check now genuinely runs against the chain's actual height on every block submission

std::vector<uint8_t>(0x40) was misread as "push byte 0x40" but actually constructs a 64-element zero-filled vector, producing a 131-byte malformed script instead of the intended 66-byte OP_RETURN. Every block's embedded XMSS public key was corrupted as a result.

The reference xmssmt_core_sign_open() writes into its output buffer at offset params.sig_bytes before copying the message to the front, but our wrapper allocated the buffer at only 32 bytes. Every single verification call overflowed the heap, corrupting the allocator and crashing the node intermittently a few allocations later. Root-caused with gdb + Valgrind (not guessed), confirmed via "Invalid read ... inside an unallocated block" trace pointing directly at the call site.

20 blocks mined back-to-back with no crash (manual binary), followed by 10 more via the production systemd service — zero failures, zero restarts, confirming the fix holds under repeated real mining load

Cross-checked every Sign() and Verify() implementation across xmss_bridge.cpp, xmss_state.h, wallet/xmss_state.h and the dead-code pouw.h for the same buffer-sizing pattern that caused Phase 6.7's heap overflow. Sign() output buffers were confirmed safe (generous fixed margins); Verify() in xmss_state.h and pouw.h were found to have the identical undersized output buffer bug and were fixed for consistency, even though pouw.h is not compiled into the build

Took a valid block, corrupted random bytes inside the witness signature, and resubmitted it 50 times via submitblock. All were correctly handled as duplicates (SegWit witness data does not affect the legacy block hash used for header identity) — zero crashes, chain state unaffected. This confirmed network-input robustness but also revealed that witness malleation means a corrupted resubmission of an existing block never reaches CheckPoUW at all

Added a temporary, environment-variable-gated code path to deliberately flip one byte of a real XMSS signature before broadcast, producing a freshly-mined block (new hash, not a duplicate). Result: AcceptBlock rejected it with pouw-invalid-sig, the node did not crash, and the chain tip did not advance — direct proof that consensus genuinely rejects an invalid PoUW signature, not just a missing one. Test code was removed immediately after confirmation

Log: "ERROR: AcceptBlock: pouw-invalid-sig, PoUW: XMSS signature verification failed"

Stood up a second, fully independent node (separate process, separate datadir, separate ports) for the first time. Direct submitblock testing showed every block ever mined was rejected with bad-witness-nonce-size — the coinbase witness must be exactly one 32-byte reserved value per BIP141, but the 2500-byte XMSS signature was overwriting that slot entirely. Confirmed the mining node only accepted its own blocks due to its own validation path, not because the blocks were actually valid.

Moving the signature to a coinbase OP_RETURN output fixed the BIP141 violation but reintroduced a circular hash dependency: adding the output changes the merkle root, which changes block.GetHash() — the very hash the signature was computed against. Diagnosed via targeted debug logging showing correct extraction but failed verification.

The signature now commits to a dedicated preimage hash (version, prevhash, time, bits, coinbase-without-signature txid, pubkey) computed and signed before the signature is attached anywhere. CheckPoUW() reconstructs the identical preimage by removing the signature output and rehashing, avoiding any dependency on the final block hash.

Submitted 3 newly-mined blocks one at a time to a completely separate node process. All accepted. Resulting chain tip hash matched the mining node's tip exactly.

Connected the two independent nodes via addnode, then mined 2 new blocks on node 1 with zero further manual intervention. Node 2's height and best-block-hash advanced automatically and matched exactly — the first time SNTI blocks have ever propagated across a real peer-to-peer connection rather than being validated by the node that mined them.

Created a genuine fork: 2 blocks mined independently on node 1, 3 blocks mined independently on node 2. On connecting the nodes, node 1 automatically reorganized to node 2's longer (more-work) chain — old blocks correctly marked orphaned (confirmations: -1), both nodes remained stable with no crashes.

Sent SNTI from a regular address to a freshly generated XMSS address, confirmed in a block, and verified the wallet correctly recognizes ownership (ismine: true) of the resulting XMSS output.

The address shown by getnewxmssaddress did not match the address shown for the same funds in gettransaction after sendtoxmssaddress — same pubkey, two different address strings. Root cause: 8 XMSS wallet RPC commands hardcoded testnet=false when calling XMSSAddr::Encode/Decode regardless of the actual active chain, while the standard EncodeDestination() path correctly checked Params().IsTestChain(). Funds were never at risk (the wallet still recognized ownership via the underlying pubkey), but this kind of address mismatch is exactly the sort of thing that could make a user believe they sent funds to the wrong place. Fixed all 8 occurrences.

Generated a new XMSS address, sent funds to it, and confirmed the address shown in the resulting transaction's details now matches the originally generated address exactly.

AddXMSSKeyToKeystore was a no-op stub from an earlier session (added only to satisfy a linker reference), and getnewxmssaddress never called it at all. Keys generated via getnewxmssaddress were therefore never registered with the ScriptPubKeyMan-level IsMine() check, so funds sent to them never appeared in listunspent. Funds were never at risk — a separate CXMSSSigner-based check still correctly reported ismine:true — but spending through the normal wallet flow was effectively blocked. Implemented the bridge and wired it into getnewxmssaddress.

The fix above only takes effect for legacy (BDB) wallets via LegacyScriptPubKeyMan. The current binary is compiled without BDB support at all (legacy wallets cannot even be created), and the default/only wallet backend available — descriptor wallets (DescriptorScriptPubKeyMan) — has no XMSS integration whatsoever. Practical result: XMSS addresses can receive funds (confirmed on-chain, confirmed via getxmssaddressinfo), but spending those funds back out through the standard wallet flow does not work in the current build. sendfromxmssaddress does not fail loudly — it silently falls back to spending unrelated wallet UTXOs instead of the requested XMSS funds. This is a genuine architecture gap, not a quick fix: properly supporting spending requires integrating XMSS into DescriptorScriptPubKeyMan, which is a substantially different data model (descriptors + HD derivation vs. a simple per-script map). Flagged here as a hard blocker for any mainnet claim that XMSS wallet round-trips work end-to-end.

pow.cpp confirmed completely unmodified from upstream Bitcoin Core — no QNT-specific changes at all. DifficultyAdjustmentInterval() correctly computes 20,160 blocks (14 days) from nPowTargetTimespan/nPowTargetSpacing, independent of any other SNTI parameter. Numerically simulated CalculateNextWorkRequired's core formula across five scenarios (on-time, 2x fast, 2x slow, 10x fast, 10x slow) — difficulty scaled exactly as expected and the 4x adjustment-bound safety clamp engaged correctly at the extremes.

While verifying retarget math, discovered nSubsidyHalvingInterval = 210,000 blocks at 60s/block produces a halving every ~146 days (0.4 years), not the "~4 years" the whitepaper explicitly promises — and not even the "~2 years" an in-code comment separately and also-incorrectly claimed. Root cause: Bitcoin's 210,000-block interval assumes 600s/block; SNTI blocks are 10x faster (60s) but the block count was never scaled up to compensate. Fixed nSubsidyHalvingInterval to 2,100,000 for mainnet, testnet, and signet (10x), restoring the intended ~4-year halving cadence. Regtest's separate 150-block interval (intentionally fast for testing) was left untouched.