[ALENOC]

Purpose and baseline

This PR merges a Core 4.8.0-based RIP-25 candidate into current RavenProject master (6d48ae0175b10283248146ae3080e2ba70966739). That master does not yet contain the v4.8.0 tag (225491298), so the direct PR diff includes both the Core 4.8.0 baseline and the incremental 4.8.1 work. The sections below describe the 4.8.1 changes relative to Core 4.8.0. For a focused view of those changes, compare v4.8.0 with the fork candidate. The candidate carries native RVN work from the historical PR #1281, adds a separate asset rule, and includes security corrections found while integrating and qualifying the code. The maintained fork candidate and release work are tracked in ALENOC/Ravencoin PR #14.

Changes compared with Core 4.8.0

Native RVN post-quantum spending

• Adds ML-DSA-44 verification and signing for native RVN witness-v2 outputs, including the 32-byte public-key program, Bech32m addresses, standard transaction policy, PQ-aware dust handling, and the NODE_PQ_HYBRID service flag. The implementation uses pinned liboqs in the depends builds.
• Adds PQ wallet key generation, ownership detection, encrypted key storage, backup and recovery paths, and getnewpqaddress and bounded recoverpqkeys RPC support. New PQ address generation is gated by activation. A historical RVN output remains spendable under its existing classical rule. An owner migrates voluntarily by sending it to a new witness-v2 PQ address; spending that new output uses ML-DSA without ECDSA.
• Introduces bit-12 BIP9 signaling. The proposed mainnet STARTED window begins 1 July 2027, times out 1 January 2029, and needs 1714 of 2016 signals followed by LOCKED_IN before ACTIVE. At activation the block limit changes from 8 to 12 MWU with a contextual discount for PQ witness data; it changes to 16 MWU after 525600 further blocks. Active native and wrapped witness-v2 spends cost two sigop units each. Versionbits, miner templates, mempool rules, and block validation use the candidate chain context.

Asset and owner-token protection

• Adds a separate bit-13 deployment, conditional on active bit 12 and the bit-8 transfer-script rule. Its proposed mainnet window begins 1 January 2029, times out 1 July 2030, and has a 1714/2016 threshold. Once active, newly created asset and owner-token outputs use the protected asset format. Spending one requires a matching native RVN witness-v2 input signed with ML-DSA-44; the asset input itself needs no ECDSA signature.
• Adds wallet, asset RPC, raw transaction, and Qt paths for protected addresses, ownership, sending, receiving, change, and migration, including getnewpqassetaddress and listpqassetaddresses. Historical asset and owner-token outputs retain their original classical spending rule until the owner moves them. Neither deployment retroactively protects existing holdings or globally disables classical signatures.
• Fails closed when a protected spend lacks its matching funded PQ anchor. Some exact-fee, dust, multiple-program, and explicit-change spends consume the anchor without refreshing it; the owner can fund the matching PQ address again. fundrawtransaction does not choose matching anchors automatically, so raw transaction callers must supply and verify them.

Security and reliability corrections

• Makes activation-sensitive validation branch-contextual across reorganization, restart, mempool, miner, and block paths. This includes the inherited Core 4.8.0 transfer-overflow deployment behavior and the RIP-25 block-weight, witness discount, sigop, undo, and relay boundaries.
• Corrects defects inherited from Core 4.8.0 and found during integration across assets, restricted assets, messaging, reward distribution, wallet encryption, mnemonic handling, recovery, and multiwallet use. It also tightens PQ witness and peer-message resource bounds, compact-block fallback, and crash/restart database replay. Findings and regressions are recorded individually in the security remediation register. Examples include wallet-scoped message state, reward restart handling, and fail-safe historical data recovery. The register identifies which defects came from Core 4.8.0 and the regression for each correction.
• Credits @skareemullah8-a11y in PR #1329 for the forged-work shortcut report and regression suggestions that prompted the FINDING-195 review. The correction preserves the inherited pre-activation height rule.
• Fixes the KAWPOW checkpoint shortcut addressed by PR #1329: only an exact indexed ancestor of an enabled checkpoint may skip full ProgPoW verification. Other headers must prove full work with a matching mix hash. The node audits saved headers from the former shortcut range on startup, rejects inconsistent disk index keys, and prevents an invalid indexed coins tip from being silently adopted. A separate correction makes the KAWPOW epoch context thread local so concurrent verification across epochs does not race. These are FINDING-195 and FINDING-196. FINDING-197 adds a configurable 256 MiB local KAWPOW context budget and handles unsupported arithmetic or allocation failure as a non-invalid resource error, without a peer penalty or failed block index status. Wrong contextual difficulty is now rejected before context allocation on both header and complete-block paths. The complete-block regression failed with a resource error before the correction, then passed with bad-diffbits; local make check passed 540 cases. Each KAWPOW claim must also meet its target before a context is built, and completed proof results are cached, so replaying a header cannot force repeated context work. A checkpoint-anchored scan of the canonical mainnet block files found that all 3,268,040 KAWPOW headers up to the height gate declare their actual height, so the largest canonical context needs 91 MiB of the 256 MiB default. Both scanners are included. FINDING-197 is fixed on the tested PR head.
• Corrects FINDING-199 from the first CI run after the KAWPOW budget change. Final Gate Windows could not link the standalone consensus library because its KAWPOW hash object referenced node-only argument symbols. The library now uses the conservative 256 MiB default while node binaries retain -maxkawpowcontextmb. The old object had unresolved gArgs and ArgsManager::GetArg references; the rebuilt object has neither, and the Windows Final Gate link passed on aa5b128c5. Startup now validates -maxkawpowcontextmb and passes it to the hash code, and ELF builds link the shared consensus library with -Wl,-z,defs, so an unresolved node symbol fails there too. That check exposed an unresolved sha256_transform in 32-bit ARM builds of the library, which now compile the existing C implementation. FINDING-199 is fixed on the tested PR head.
• Fixes two wallet-disabled Qt startup and Options crashes inherited from Core 4.8.0. The build uses pinned dependencies, and the release workflow checks source provenance, target formats, installer contents, and the macOS app payload across its packages.

Verification performed

The current PR head is 2819fbae571dcc1e8a6379d0465571bdd003cb8d, a local no-ff integration of the updated Core 4.8.0-based fork candidate into the older official master baseline. It differs from the RC2 source e3356f3f1 only in documentation that records the RC2 pre-release, and Build Raven #40645974986 and Final Gate #40645975041 passed on this exact SHA. On e3356f3f177be59151edd8de1add19fc61e71d37, Build Raven #40609746431 and Final Gate #40609746325 passed, including required security tests, all five release targets, the aggregate bundle verifier, and all seven Final Gate variants. Every ELF variant linked the consensus library with -Wl,-z,defs, and the Windows library link passed. Its five packages passed an independent download review against the source checkout, the packaged Linux Qt application passed the wallet-disabled smokes, and the packages are published as the unsigned v4.8.1-rc2 pre-release. The earlier head a756574d4 passed Build Raven #40599833317 and Final Gate #40599833429. Local make check passed 546 test_raven cases on fork source ccb576e13; under src/, this head adds only the 32-bit ARM sha2.c correction, which leaves the x86_64 object unchanged. All 29 focused KAWPOW cases passed. The KAWPOW tests cover forged work, checkpoint siblings, saved invalid branches, concurrent epochs, extreme declared heights, claimed-target checks before context allocation, replayed proof results, allocation failure, local resource errors, valid-header retry after raising the budget, and early bad-difficulty checks for headers and complete blocks. Structural and behavioral invariants with their negative controls, all 14 required functional tests under Python 3.10, the release contract, and both scanner self-tests passed locally.

A binary built from fork candidate 6dcf85d9e, with the same KAWPOW code as this head, ran on the public unpruned testnet database with assumevalid=0. It accepted 532 new KAWPOW blocks through height 2,571,017, passed verifychain 4 2016 before and after a restart, and accepted three more blocks through height 2,571,020. Earlier, the exact aa5b128c5 binary passed verifychain 4 2016 twice and accepted blocks through height 2,570,490 with bit 12 STARTED and bit 13 DEFINED. These runs confirm historical compatibility and continued validation, not live activation of the proposed rules.

PR head aa5b128c565104c19c9ba9837797acaae4983f4c passed Build Raven #40499782364 and Final Gate #40499782271, including the Windows consensus-library link, and local make check passed 540 cases there. The next fork candidate c76826b36 failed Final Gate #40594373087 only in its two 32-bit ARM variants, on the sha256_transform link error corrected above.

The earlier PR head 30349977b90b8e1743a3948d3f613090b3e78523 passed Build Raven #40455702783, including all five release targets and the aggregate bundle verifier. Final Gate #40455702781 passed its required security job and six platform builds, but Windows failed linking the consensus library, as recorded in FINDING-199. Its testnet binary reopened the unpruned chain and passed verifychain 4 2016 at height 2,570,118. These results are historical and do not qualify this new SHA.

The earlier PR checkpoint c63cad804e606211b3c87ff84d14ca3dff9c9c44 passed Build Raven #40327113350 and RIP-25 v4.8 Final Gate #40327113034. Their required security jobs, all five release targets, aggregate package check, and seven Final Gate variants succeeded. A separate download review of all five bundles passed exact-checkout source, common source archive, manifest, provenance, target binary-format, Windows installer, and complete macOS app checks. Their common source archive SHA-256 is 77665286b6a2a5c0a100ae5342b266d7139e0f3160633ca4a0404d2807b3e6b1. The extracted Linux package passed wallet-disabled Qt startup and Options interaction under Xvfb. The unpruned public testnet node reopened its existing history with that binary at height 2,569,434, accepted later blocks, and returned true for verifychain 4 2016. These results do not qualify the new head.

The fork source at 1e1dfde159c6feace73459c6b9a1b8dbb87456df passed local make check and its eight-case release-document contract. Its exact-SHA Build Raven passed its required security job, including make check and all 38 functional tests, all five release target builds, and the aggregate downloaded-bundle verifier. A separate review of its five downloaded bundles confirmed the same checks, with source archive SHA-256 67c3d1ff7b5ca759c7d54e47edc51814eec34d46b9e7c1b6e3165f0558d0a151. Its packaged Linux Qt application passed both wallet-disabled smokes. Its Final Gate passed its security job, including make check and all 38 functional tests, and all seven platform build variants. Earlier exact-SHA fork runs passed both workflows and independent five-package provenance checks; the downloaded Linux Qt package passed node-only startup and Options interaction under Xvfb.

The unpruned public testnet database was replayed from genesis with assumevalid=0 and synchronized with peers. The current fork binary 1e1dfde15 reopened it at height 2,567,901 and passed verifychain 4 2016. An earlier full active-chain scan through height 2,563,374 found no witness-v2 outputs or spends. The later 1e1dfde15 deep check demonstrates continuing historical compatibility, not a live public-network PQ activation. Regtest covers bit-12 and bit-13 activation boundaries, reorganization, wallet, and asset behavior. Public testnet force-enables the native PQ rule from genesis, so its current 16 MWU template cannot prove the mainnet 8-to-12-MWU BIP9 transition.

Rollout and review status

The bit-12 weight change is incompatible with Core 4.8.0 validation after activation. Miners, pools, full nodes, exchanges, custodians, and dependent services need to upgrade before ACTIVE; signaling alone does not update validators. An upgraded 4.8.1 miner template automatically signals bit 12 during STARTED and LOCKED_IN, so the operator go/no-go must be settled before that window. FINDING-197 and FINDING-199 are fixed on the tested head. FINDING-067 remains HIGH and OPEN for operator readiness, the bit-12 go/no-go, and final stable release steps. The local KAWPOW budget is an operator resource limit, not a consensus height rule. The fork v4.8.1-rc2 pre-release publishes eight unsigned evaluation distributions from e3356f3f1 and SHA256SUMS-unsigned.txt. All nine uploaded assets were downloaded again and matched their SHA-256 digests. RC2 supersedes v4.8.1-rc1, which predates the KAWPOW corrections and whose Linux ARM32 consensus library fails to load. Native Windows and macOS GUI use has not been tested and is assigned to community testing after publication. Cross-platform compilation and package inspection do not prove native GUI behavior or reproducible builds.

Please review consensus compatibility at activation, KAWPOW header verification and its remaining resource limit, asset parsing and anchor enforcement, wallet custody and recovery, raw funding, Qt behavior, and the release checks. This PR requests code review and does not authorize bit-12 activation or a final stable release. The 4.8.1 release notes describe the proposed operator sequence and migration path.

The public status and handoff note summarizes decisions, evidence, and remaining work. It is included in the current PR head; it does not make the RC1 or RC2 artifacts representative of a later head.