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 added to the build

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

XMSS-SHA2_10_256 key pair. Private key stored in 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 SNTI-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.

Internal deep audit completed 29 Jun 2026 — 12 bugs found & fixed (5 critical, 5 high, 2 medium). External audit (Trail of Bits/Halborn) planned for Q4 2026.

3 seed nodes active: Main VPS (104.234.26.7 — Indonesia), Seed-US (166.88.227.172 — Kansas City), Seed-APAC (103.195.190.192 — Singapore). DNS seed: seed/seed2/seed3.assentian.network.

Mainnet genesis mined 26 Jun 2026. Hash: b4a26aef52f6f5038815f26917cb0ea1fd3b3b13fbc7cfb5c541088a6943a5ba. nBits: 0x2001a41a. Message: "Assentian-PQE 22/Jun/2026 XMSS Post Quantum Era - For Sentia"

assentian.network live with SSL. Block explorer, web wallet, investor roadmap, and mining installer all available. VPS miner running 24/7. Block 1170+ as of 30 Jun 2026.

pouw_v2_keyder.h:104-109 — HKDF now outputs 96 bytes (SK_SEED 32 + SK_PRF 32 + PUB_SEED 32). It previously produced only 32 bytes, yielding an invalid seed.

xmss_keystore.h:229 — guard added: returns 0 if leaf_index >= 1024 (previously underflowed to a huge value). Prevents a false-positive "key still has signatures left".

Verified directly: nPoUWv3StartHeight=200 is identical in mining.cpp and validation.cpp. No actual bug — the code is correct.

wallet.cpp:2193-2194 — signing is now rejected while the wallet is locked, preventing WOTS+ leaf reuse without valid XMSS state persistence.

sm_buf_size is now computed dynamically from params.sig_bytes instead of a hardcoded value. Prevents buffer overflow/underflow with different XMSS parameters.

mining.cpp:307-312 — SK_SEED(32), SK_PRF(32), PUB_SEED(32) are now read separately (instead of a contiguous read that picked up the root hash as PUB_SEED).

validation.cpp — size check added for the PoUW proof (pouw-sig-too-large) and FSL data (pouw-fsl-too-large) before Deserialize is called.

xmss_signer.cpp:417 — script.size() == 66 (not 65). P2XMSS = PUSH64(1) + pubkey(64) + OP_XMSS_CHECKSIG(1) = 66 bytes total.

xmss_bridge.cpp — added verification that the recovered message == original hash after xmss_sign_open. Prevents a false-positive if it returns 0 but the recovered message differs.

chainparams.cpp — regtest nXMSSChainId = 4 (previously 3, same as signet). Now: mainnet=1, testnet=2, signet=3, regtest=4.

pow.cpp:101 — clamps min_target to 1 if old_target / 4 == 0. Prevents a lower-bound bypass and a potential division-by-zero.

validation.cpp:1707 — comment updated to: "2,100,000 blocks (~4 years at 60s/block)". Previously stated the wrong number.

One XMSS tree was reused for 11 blocks within ~2 seconds (all identical timestamps). The EMA computed a block time of ~0s → EMA jumped 2× → target became too tight (~14,000 trees/block = est. 9.6 hours/block). RPC overload because GenerateBlock blocked the HTTP thread for the whole PoUW process.

pouw_v2.h — EMA clamp raised from a 4× to a 20× baseline. Recovery ratio per slow block rose from 1.3× to 2.9×, so a stuck chain no longer needs hundreds of blocks to recover.

pow.cpp — if the time since the last block > 10× the target spacing (10 minutes), use nFirstBlockTime to force a 20× EMA recovery. Prevents the chain from getting permanently stuck.

pow.cpp — max difficulty swing per period raised from 4× to 20× so stuck-chain recovery blocks can be validated by other nodes.

rpc/mining.cpp — limits each RPC call to 20 trees (~50 seconds). The miner retries automatically. RPC stays responsive for other requests during PoUW mining.

After rebuilding and restarting services at 12:03 UTC, the chain recovered immediately. Block 297 was found with nBits=0x1f0dd8d7 (2.9× easier). The chain kept mining normally up to 786+ blocks as of 29 Jun 2026.

Binary c3070e74 deployed to 2 new seed nodes. Passwordless SSH via ssh-copy-id. assentian-seed.service active and auto-starting.

chainparams.cpp updated with 3 vSeeds: seed/seed2/seed3.assentian.network. DNS A records created at Rumahweb (round-robin across seeds). New nodes automatically discover peers via DNS with no manual configuration.

Main VPS: assentian-vps-miner (full core). Seed-US: assentian-seed-miner (1 core, address snti1zhms7...). Seed-APAC: assentian-seed-miner (1 core, address snti1zcaf64...). All in sync at block 1170+.

Transferred 10 SNTI from asep's wallet to dani's wallet successfully. Custodial web wallet fully functional for send/receive. Non-custodial watch address also working.

snti-coin.svg updated: modern vertical-stretch S, blockchain node network background, 4-cluster star constellation, 7 gold lines. Favicon applied across 11 HTML pages.