. #35204

af14f233a55d290cacb4d0a5aba325e0383b04bc ci: don't build using `-Werror` when using Clang (Kittywhiskers Van Gogh)
3b837c8d16084fde6d025fe5a3ad75b08c55ed56 ci: don't build using `-Werror` when using GCC (Kittywhiskers Van Gogh)
04e036e99eb49d7a1e51968923dd97741456c583 revert: make fuzzing builds stricter by enabling -Werror by default (Kittywhiskers Van Gogh)
29090a045925bdcdae114cfbaf6fccdfd7ff00d1 merge bitcoin#25972: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set (Kittywhiskers Van Gogh)
d0548f8b1c51475c67e2b2cf0e2e46cd23405bc3 merge bitcoin#29486: remove -Wdocumentation conditional (Kittywhiskers Van Gogh)
0f4812f4d089422d47820430e4c1689a1571fb61 merge bitcoin#27872: suppress external warnings by default (Kittywhiskers Van Gogh)
71007801e8dfd1f793b782533f7b84b80df84e2c merge bitcoin#28999: Enable -Wunreachable-code (Kittywhiskers Van Gogh)
5471c58319a38435227d9efc6a680d3c57c31ef7 merge bitcoin#28092: document that -Wreturn-type has been fixed upstream (mingw-w64) (Kittywhiskers Van Gogh)
9098c9cc1101049269ff0586a146bf6069317f85 build: always enable -Wsuggest-override (Kittywhiskers Van Gogh)

Pull request description:

  ## Motivation

  While working on [dash#6633](https://github.com/dashpay/dash/pull/6633), I had built `develop` (5e4a8927a4a35a3c7e352915cdeb3ac1fb30d4da) but the build _failed_ locally due to a `-Wthread-safety` warning (see below) that was introduced by [bitcoin#25337](https://github.com/bitcoin/bitcoin/pull/25337) ([commit](https://github.com/dashpay/dash/commit/a7d4127ea87c64d7015c7650c60025f4758fdbe4)). It was caught because I use additional `CXXFLAGS` on my local system but it _should_ have been caught by CI, especially since [bitcoin#20182](https://github.com/bitcoin/bitcoin/pull/20182) ([commit](https://github.com/dashpay/dash/commit/14a67ee85edb2a38d23658e4d9c103d11d87f154)) made `--enable-werror` the default for CI and the sole exception (the Windows build) was remedied with [bitcoin#20586](https://github.com/bitcoin/bitcoin/pull/20586) ([commit](https://github.com/dashpay/dash/commit/750447e345d9f3fcae3d8a63fe7baac5224bfac0)), so every build variant should've run with `-Werror`.

  <details>

  <summary>Compile error:</summary>

  ```
    CXX      wallet/libbitcoin_wallet_a-sqlite.o
  wallet/rpcwallet.cpp:1038:36: error: calling function 'IsMine' requires holding mutex 'wallet.cs_wallet' exclusively [-Werror,-Wthread-safety-analysis]
   1038 |         isminefilter mine = wallet.IsMine(address);
        |                                    ^
  ```

  </details>

  But that didn't happen. Till [bitcoin#23149](https://github.com/dashpay/dash/commit/70ed6b47f952bacd37d69a39c6fe122e7668cb49), there were a separate set of warnings (overridable by `CXXFLAGS`) and errors (overridable by `CXXFLAG_WERROR`). _Before_ the backport, coverage was as expected ([build](https://gitlab.com/dashpay/dash/-/jobs/9221165750#L786), search for `-Werror=thread-safety`) but _after_ the backport, `thread-safety` (and other expected warnings) were no longer being evaluated ([build](https://gitlab.com/dashpay/dash/-/jobs/9238308844#L740), search for `-Werror` and `-Wthread-safety`, only the former is present).

  Expected `CXXFLAGS`:

  ```
  CXXFLAGS            =  -O0 -g3 -ftrapv -fdebug-prefix-map=$(abs_top_srcdir)=. -Wall -Wextra -Wgnu -Wformat
                         -Wformat-security -Wreorder -Wvla -Wshadow-field -Wthread-safety -Wloop-analysis
                         -Wredundant-decls -Wunused-member-function -Wdate-time -Wconditional-uninitialized
                         -Woverloaded-virtual -Wsuggest-override -Wunreachable-code-loop-increment
                         -Wimplicit-fallthrough -Wno-unused-parameter -Wno-self-assign -Werror
                         -pipe -std=c++20 -O2 -O0 -g0
  ```

  Actual `CXXFLAGS`:

  ```
  CXXFLAGS            =  -O0 -g3 -ftrapv -fdebug-prefix-map=$(abs_top_srcdir)=. -Werror -pipe -std=c++20 -O2 -O0 -g0
  ```

  This happened because `CXXFLAGS` are overridden by default which results in none of the warnings making it to the final `CXXFLAGS`, which reduced the effectiveness of `-Werror` substantially (while `CXXFLAG_WERROR` was left undisturbed, which allowed pre-backport builds to include coverage). This is remedied by backporting [bitcoin#25972](https://github.com/bitcoin/bitcoin/pull/25972) (done by this PR), which will ensure that `WARN_CXXFLAGS` are included _even if `CXXFLAGS` are overridden_ and is possible because [bitcoin#24391](https://github.com/bitcoin/bitcoin/pull/24391) ([commit](https://github.com/dashpay/dash/commit/11323c38511f1e5b8e1a8154124f736628db6b76)) is already in `develop`.

  ## Additional Information

  * Dependency for https://github.com/dashpay/dash/pull/6638

  * Dependency for https://github.com/dashpay/dash/pull/6639

  * Because the warnings (converted to errors with `-Werror`) cast a wider net than the older set of error flags, `develop` in its current state does not compile. To allow CI to bless this PR, `-Werror` for both Clang and GCC-based builds have been  **tentatively** disabled and will be re-enabled by the dependent PRs listed above.

    It is recommended to read the pull request description for both dependents while reviewing this PR.

  * `-Wsuggest-override` was made unconditional in [bitcoin#28348](https://github.com/bitcoin/bitcoin/pull/28348) ([commit](https://github.com/dashpay/dash/commit/c71e3df8b48db29a860c5b7207e663435909ebd2)) **but** there were two such conditional checks, they were deduplicated in [bitcoin#23149](https://github.com/bitcoin/bitcoin/pull/23149) but the former was merged before the latter (i.e. out-of-order) and one conditional check lingered around. This lingering check has been removed as we don't support GCC 9.2.

  * `CXXFLAGS` set for the fuzz build ([commit](https://github.com/dashpay/dash/commit/184bd6031ba10b9a5defdaa6512a8ab832f169ac)) that enabled `-Werror` are made redundant with [bitcoin#20182](https://github.com/bitcoin/bitcoin/pull/20182) and therefore, have been removed.

  ## Breaking Changes

  None expected.

  ## Checklist

  - [x] I have performed a self-review of my own code
  - [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)**
  - [x] I have added or updated relevant unit/integration/functional/e2e tests **(note: N/A)**
  - [x] I have made corresponding changes to the documentation
  - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_

ACKs for top commit:
  UdjinM6:
    utACK af14f233a55d290cacb4d0a5aba325e0383b04bc

Tree-SHA512: ccdaf71cf79eb3aec2468c4c1eaa696cd120c03e9665a3c4b56da6ef17cca9585ef8c66ac1625f2ba243c7f80f15e92a336c0bd90b5f11969fabb3adde3c8125

7231c7630e61c062440459963f7b00ccbec68f0f qt: Replace deprecated LogPrintf with LogInfo in GUIUtil::LogQtInfo() (Hennadii Stepanov)
b3d3ae0680e7529853413de045aa9fbd7ac51e5c qt, build: Drop `QT_STATICPLUGIN` macro (Hennadii Stepanov)

Pull request description:

  Broken out of https://github.com/bitcoin/bitcoin/pull/30454.

  Our `QT_STATICPLUGIN` macro is effectively equivalent to the Qt's `QT_STATIC` macro.

  It is easy to see in the `_BITCOIN_QT_IS_STATIC` macro implementation: https://github.com/bitcoin/bitcoin/blob/ebd82fa9fae13d5a7a395800295dd7fd34185b58/build-aux/m4/bitcoin_qt.m4#L269-L292

  No need to handle both macros.

ACKs for top commit:
  maflcko:
    re-ACK 7231c7630e61c062440459963f7b00ccbec68f0f
  TheCharlatan:
    ACK 7231c7630e61c062440459963f7b00ccbec68f0f

Tree-SHA512: abbf21859b7ac2aaf47c5b0e075403e4cc9bc540b1565d23f51650b8932dde314586aca67fd4ed5daadebc89268baf8c18f65348fa2b836078ac24543c14cfd6

This reverts commit 9304688885d9df8e9535ff137e841e8ce2695b51.

excludes:
- 27f353d8efca19bc2f7dc79b09d4737c9401a768

This reverts commit d1d7fbb270c5b3e1a0a9aa4a7bb5a1a7ef4a2543.

This reverts commit 8326838d24c26abf7727e5416418d34034e970ae.

in btc the outbound check is true for relevance.

merge master

Poda refactor

will put up to 1728 lists in memory and clean up on flush or flush on hard flush (like shutdown) regardless. Will prevent continuous growth of disk for DBs that don't reach full cache (like DMN list) on every flush (which happens every hour at runtime).

Also batch write up to a maximum to avoid large memory upticks during writing (applicable to txroots, dbindex, evodb lists of 256 or greater)

this will allow proper timely propogation of verified sigs, because node1 was reindexed

saw logs in tests showing initial snapshot, tipindex is updated on a new block before processblock is called, so update tipindex only when we know a new tip was written to cache and when getting the list should check the previous block incase the current is missing (due to timing of processblock vs updateblocktip)

set tipindex based on calling thread in validation to ensure tipindex is set after processblock.

Remove prev tipindex update logic

Currently, `-Warray-bounds` is triggered by `immer` code and
`-Wdangling-reference` is triggered by UniValue-adjacent code.

Co-authored-by: Konstantin Akimov <knstqq@gmail.com>

It reduces memory consumption for classes CBLSLazySignature and CBLSLazyPublicKey

    sizeof(CBLSLazyPublicKey)=344 down to 336
    sizeof(CBLSLazySignature)=536 down to 528

During full index close to ~1Bln of CBLSLazyPublicKey objects are created and destroyed
as members of CDeterministicMNState and CSimplifiedMNListEntry with peak in memory close to ~1Mln

It gave a bit of RAM saving (roughly 8Mb in peak) and a bit of CPU saving by being
a more cache friendly.

CBLSLazySignature is not used as widely as CBLSLazyPublicKey

7057df474ee6144b4b25b839af034d880e03073f test: trivial fixes to resolve review comments (Konstantin Akimov)
d82c39c83fa8a0f5795819abe63d81fd7011520e test: split feature_llmq_simplepose.py for cases of spork23 and no spork23 (Konstantin Akimov)
5767344d31bc12bf07877b58ec4f5721a5a94bf4 test: check for banned or punished masternodes for each quorum in each test (Konstantin Akimov)
f72c6f2feb893e5a7debdadb899642a9604fdf14 test: correctly pass mninfo_valid to mine_quorum for feature_llmq_dkgerrors.py (Konstantin Akimov)
2f3260e9c1df942b6f9fbf43839af1fe42f9c94e test: move general checks for Masternode from feature_llmq_simplepose.py to test_framework/masternodes.py (Konstantin Akimov)

Pull request description:

  ## Issue being fixed or feature implemented
  The functional test `feature_llmq_simplepose.py` is the slowest one and its run alone is taking longer time than all other functional tests all together (running in simultaneous jobs).
  ```
  Remaining jobs: [feature_llmq_simplepose.py]
  285/285 - feature_llmq_simplepose.py passed, Duration: 294 s

  ...
  feature_llmq_simplepose.py                         | ✓ Passed  | 294 s
  ...

  ALL                                                | ✓ Passed  | 6078 s (accumulated)

  Runtime: 294 s
  ```

  ## What was done?
  Done 2 major refactors that improved performance:
  1. split functional test to 2 version: with spork23 activated and spork23 disabled
  2. checks "there's no pose ban or no pose punishement" are done now for each successfully generated quorum in `mine_quorum` helper instead dedicated quorum generations in `feature_llmq_simplepose.py`

  It should also increase reliability of `feature_llmq_simplepose.py` because it generate less quorums in each run and in total.

  ## How Has This Been Tested?
  Total time of test-suite is dropped from 294seconds to just 249seconds (while running locally in 30 parallel jobs `-j30` built with `-O3`):
  ```
  267/286 - rpc_help.py passed, Duration: 2 s
  Remaining jobs: [feature_llmq_data_recovery.py, feature_block.py, p2p_quorum_data.py, feature_llmq_simplepose.py, feature_governance.py --legacy-wallet, feature_governance.py --descriptors, feature_csv_activation.py, p2p_addr_relay.py, p2p_compactblocks.py, p2p_add_connections.py, p2p_blockfilters.py, p2p_sendtxrcncl.py, feature_anchors.py, p2p_node_network_limited.py --v1transport, p2p_node_network_limited.py --v2transport, p2p_permissions.py, feature_config_args.py, feature_settings.py, feature_dirsymlinks.py]
  268/286 - feature_llmq_simplepose.py passed, Duration: 195 s

  ...
  feature_llmq_simplepose.py                         | ✓ Passed  | 195 s
  feature_llmq_simplepose.py --disable-spork23       | ✓ Passed  | 105 s
  ...
  ALL                                                | ✓ Passed  | 5998 s (accumulated)
  Runtime: 249 s
  ```

  Also there's no more outsiders amongs functional tests: the slowest functional tests are even slow:
  ```
  feature_llmq_simplepose.py --disable-spork23       | ✓ Passed  | 105 s
  feature_llmq_connections.py                        | ✓ Passed  | 106 s
  p2p_sendheaders_compressed.py                      | ✓ Passed  | 114 s
  p2p_sendheaders.py                                 | ✓ Passed  | 117 s
  feature_llmq_chainlocks.py                         | ✓ Passed  | 122 s
  p2p_addr_relay.py                                  | ✓ Passed  | 128 s
  feature_csv_activation.py                          | ✓ Passed  | 130 s
  p2p_tx_download.py                                 | ✓ Passed  | 137 s
  feature_llmq_is_retroactive.py                     | ✓ Passed  | 139 s
  feature_asset_locks.py                             | ✓ Passed  | 142 s
  feature_governance.py --descriptors                | ✓ Passed  | 180 s
  feature_governance.py --legacy-wallet              | ✓ Passed  | 181 s
  feature_maxuploadtarget.py                         | ✓ Passed  | 190 s
  feature_llmq_simplepose.py                         | ✓ Passed  | 195 s
  feature_block.py                                   | ✓ Passed  | 196 s
  feature_llmq_data_recovery.py                      | ✓ Passed  | 199 s
  p2p_quorum_data.py                                 | ✓ Passed  | 209 s
  ```

  ## Breaking Changes
  N/A

  ## Checklist:
  - [x] I have performed a self-review of my own code
  - [x] I have commented my code, particularly in hard-to-understand areas
  - [ ] I have added or updated relevant unit/integration/functional/e2e tests
  - [ ] I have made corresponding changes to the documentation
  - [x] I have assigned this pull request to a milestone

ACKs for top commit:
  UdjinM6:
    utACK 7057df474ee6144b4b25b839af034d880e03073f
  PastaPastaPasta:
    utACK 7057df474ee6144b4b25b839af034d880e03073f

Tree-SHA512: dc01dc5a9e22e2da3ee8e1abfb864fbe23f3f722b890a0723054f1551a6c8c01b43ff133f63d8d2121a9f2af34c5a515802b517a6d7f379bb8450368739a9b8e

within an existing quorum we want to show that stopping CL's can start again once nodes start again. Proves that node data exists to continue CL signing without needing anything from peers.

useful for l2's to know if data was finalized prior to batch submission

persist SB db which demands on block reward on reindex, otherwise payment limits won't be consistent.

prev we wrote an empty byte if we pass in SER_NO_PODA as type which is used by the raw tx RPC API but this may trip some parsers (like electrumx and blockbook) doing bitcoin based parsing of txout with an unexpected extra byte '00'. Now we simply skip it and ensure the SER_NO_PODA is applied on every decode and encode where SER_NETWORK is applied (for any tx/block SER/DER)

Link NEVM to go-ethereum repository

Update README.md

1) were not returning chainlock/block index information if VH was passed into getnevmblobdata. Wrote test to confirm fix.
2) small issue on txid being passed return type of NUM instead of STR_HEX
3) cosmetic counter fix in prune code

adds quorum to canonicalize btc prev hash auxpow blocks for nevm precompile access

Introduce optional btcheadernode integration for sentry policy/signing, including watchdog restart/reindex recovery and deterministic Guix build plumbing. Package `bitcoind`/`bitcoin-cli` in Linux release artifacts and add end-to-end policy tests for fork, stall, and recovery behavior.

-  (`fork` -> safer spawn): managed BTC node startup now uses `posix_spawn` in `src/validation.cpp` (with spawn attrs/file actions), not in-process `fork/exec`.
-  (no shell-string command ambiguity): RPC invocation uses argv vectors via `RunCommandParseJSON(const std::vector<std::string>& ...)` in `src/common/run_command.*`, wired through `GetManagedBTCHeaderRPCCommandArgs` and `RunBTCHeaderRPCCommand`.
- (recent-fork heuristic tuning): `recentForkDepth` is guarded by `> 0` and configurable via `-btcheaderrecentforkdepth`; default is `2` in `src/validation.h`.
- (max lag guard): `-btcheadermaxlagblocks` is implemented (default `36`) with deny path `btc-candidate-too-old(...)` in `src/llmq/quorums_btccheckpoints.cpp`.
- (continuity persistence across restart): continuity baseline is re-derived from chain state via `GetLatestOnChainBTCPREVCommitment`, and `lastSignedBTCHash/lastSignedBTCHeight` are initialized from that baseline.
- (clock-skew mitigation): height-progress staleness check exists via `lastPolicyObservedTipHeight` / `lastPolicyTipProgressTime` plus `-btcheadertipmaxnoprogress` (default `1800`), alongside `tipmaxage`.

use check_sigs instead

VerifyBTCCheckpointShare returns true early on a sigChecked cache hit without populating the ret output parameter. Callers like HandleNewRecoveredSig rely on ret.first to set the correct signer bit (share.signers[ret.first] = true) and on ret.second to key into bestShares. On a cache hit, ret retains its default-initialized values (first=0, second=nullptr), leading to the wrong signer bit being set and a nullptr key inserted into the shares map.

VerifyBTCCheckpointShare's cache-hit path calls llmq::quorumManager->ScanQuorums() while holding cs. Comments in ProcessMessage explicitly document that cs_main must be acquired before cs (LOCK2 ordering). If ScanQuorums internally needs cs_main, the lock order cs → cs_main inverts the documented cs_main → cs order used elsewhere (e.g., consensus validation in ProcessSpecialTxsInBlock), creating an ABBA deadlock risk. The non-cache path correctly calls ScanQuorums outside the cs lock scope.

The two RunCommandParseJSON overloads (string and vector forms) contain nearly identical implementations: the collect_stream lambda, thread-based stdout/stderr collection, c.wait() + join pattern, error checking, and JSON parsing are copy-pasted verbatim. A shared helper that accepts an already-constructed bp::child would eliminate the duplication and ensure bug fixes (e.g., to stream handling) apply to both paths.

receiptRequired uses absolute modular arithmetic (height % BTCCHECK_PERIOD == BTCCHECK_CARRIER_OFFSET) with only height >= start gating. If nCLReceiptStartBlock falls between the sign offset and carrier offset within a period, the first carrier block after activation requires a receipt for a sign height that preceded activation — when no quorum would have been signing. Since the receipt cannot be null (it must pass ExtractBTCCReceipt), miners must include the magic bytes with a null-valued CBTCCheckpointSig, which is an undocumented requirement at activation boundaries.

The preprocessor guard for Boost.Process was changed from ENABLE_EXTERNAL_SIGNER to HAVE_BOOST_PROCESS, but HAVE_BOOST_PROCESS is only defined when --with-boost-process resolves to yes. Since auto (the new default) resolves to no unless --enable-btcheadernode-build is set, builds with --enable-external-signer that previously worked will now hit the runtime exception path ("RunCommandParseJSON requires Boost::Process support") because HAVE_BOOST_PROCESS won't be defined. The old code compiled Boost.Process under ENABLE_EXTERNAL_SIGNER regardless of the --with-boost-process flag.

VerifyAggregatedBTCCheckpointNoCache checks that quorums_scanned is non-empty but does not verify its size equals signingActiveQuorumCount. The threshold check on line 709 counts declared signers from btcsig.signers, but the verification loop only iterates over quorums_scanned.size(), which ScanQuorums may return fewer of than requested. Signers at indices beyond quorums_scanned.size() are silently ignored during BLS verification, allowing the threshold check to pass with fewer cryptographically verified signers than declared.

DUMMY_VERSION and DISK_INDEX_VERSION_BTCPREV are both set to 260000, so the btcpPrevCommitment field is unconditionally serialized for every block index record written after this change, including the vast majority of blocks that have a null commitment. Since the version check is _nVersion >= DISK_INDEX_VERSION_BTCPREV and _nVersion is always initialized to DUMMY_VERSION, every newly written record includes the extra 32-byte field regardless of whether it carries meaningful data. This inflates the block index database for all records.

ExtractBTCCReceipt and ExtractBTCPREVCommitment search for the last occurrence of their 4-byte magic sequences in the coinbase payload. If the serialized CBTCCheckpointSig (which contains a 48-byte BLS signature of essentially random bytes) or the uint256 hash happens to contain the magic byte sequence (btcc or btcp), the search finds that false match inside the payload, deserialization starts from the wrong offset, and the function returns false. Since this is a consensus-critical check (bad-btcc-missing / bad-btcp-missing), a valid block would be rejected by all nodes. The existing GetNEVMData function uses first-occurrence search, which avoids this class of issue.

The public: label added before DISK_SNAPSHOT_PERIOD exposes all three constants (DISK_SNAPSHOT_PERIOD, DISK_SNAPSHOTS, and LIST_CACHE_SIZE) when only LIST_CACHE_SIZE is needed externally (in init.cpp). The private: label follows later but the two intermediate constants become part of the public API unnecessarily, increasing the class's public surface area.

Deny signing for the current Syscoin height after continuity rebaseline when the previously signed BTC hash is no longer in the active BTC chain, preventing same-height sign/deny oscillation. Also queue AsyncSignIfMember outside CBTCCheckpointsHandler::cs to avoid cs/cs_main lock-order inversion under DEBUG_LOCKORDER.

Always clean the helper Bitcoin CMake build directory before configure to avoid cache drift (e.g. stale ENABLE_IPC). Expand the build fingerprint to include compiler paths/flags and script digest so environment or script changes reliably trigger rebuilds.

The continuity guard in CheckBTCHeaderSigningPolicy calls RunBTCHeaderRPCCommand({"getblockhash", ...}). bitcoin-cli getblockhash N outputs a bare hex string (e.g. 0000abcd...) without JSON quotes, which is not valid JSON. RunCommandParseJSON / WaitParseJsonFromChild calls UniValue::read() on this output and throws, causing RunBTCHeaderRPCCommand to return false. This makes the continuity guard always fail after the first successful signing cycle, permanently blocking subsequent BTCC signing with deny reason btc-prev-signed-active-chain-lookup-failed.

In WaitCollectOutputFromChild, std::thread objects stdout_reader and stderr_reader are created before process.wait() is called. If process.wait() throws (e.g., std::system_error from an OS-level waitpid failure or signal interruption), stack unwinding destroys the still-joinable threads, and std::thread's destructor calls std::terminate(), crashing the process. A RAII wrapper or try/catch around process.wait() that joins the threads before re-throwing would prevent this.

WaitCollectOutputFromChild hardcodes "RunCommandParseJSON error" in its error message, but it's also called by the new RunCommand overloads. When a non-JSON command fails, the error message incorrectly attributes the failure to RunCommandParseJSON, which could confuse debugging of BTC header node RPC command failures.

The four RunCommand/RunCommandParseJSON variants (string-based and vector-based, raw and JSON) each duplicate the same ~12-line boilerplate for stream declarations, empty-input guard, stdin piping, and pipe close. The string and vector variants differ only in how bp::child is constructed; the JSON and raw variants differ only in whether ParseJSONResult wraps the output. A single internal template helper parameterized on child-construction and result-processing would eliminate roughly 40 lines of redundant logic and reduce the risk of future inconsistencies when the pattern needs updating.

When DoBTCHeaderStartupProcedure fails, btc_header_policy_ready is set to false immediately, but the fatal InitError is deferred until after the geth startup loop, which can block for up to gethstartuptimeout seconds (default 14400 = 4 hours). A masternode operator whose BTC header backend is misconfigured could wait hours only to see an abort that was already determined at the start. Moving the policy-ready check before the geth wait loop (or returning early) would give faster user feedback.

In ProcessSpecialTxsInBlock, GetSyscoinData is called at line 160 and its vchData result is only used for a data_size log message. Then ExtractBTCCReceipt is called at line 168, which internally calls GetSyscoinData again on the same coinbase transaction. The first extraction is redundant — passing vchData directly into the tag-search logic or extracting once and reusing would avoid duplicate coinbase parsing on every carrier-height block.

The $(BTCHEADERNODE_BIN_STAMP) target depends only on the build script and bitcoin.lock, but not on the actual patch file referenced by BITCOIN_PATCH in the lock file (contrib/btcheadernode/patches/headers-only.diff). If the patch file content changes without bitcoin.lock or the build script changing, make won't re-invoke the build script, leaving stale bitcoind/bitcoin-cli binaries. The build script's internal fingerprint would detect the stale state only on a forced re-run, not during a normal make.

DEFAULT_BTC_HEADER_MAINNET_P2P_PORT (18444) and DEFAULT_BTC_HEADER_MAINNET_RPC_PORT (18443) are identical to Bitcoin Core's regtest default P2P and RPC ports. While this avoids conflicts with a Bitcoin mainnet node running on the same machine, any operator also running a Bitcoin Core regtest instance will experience port conflicts. This is the default-on configuration for masternodes (DEFAULT_BTC_HEADER_MANAGED is true), meaning a managed bitcoind will silently fail to start if those ports are occupied, potentially causing BTCC signing to stall.

Prevent the DMN EvoDB from growing across repeated shutdowns when the dirty
cache is below the 1728-snapshot retention window.

On forced flush, merge persisted snapshots with dirty in-memory entries and
rewrite only the newest 1728 live snapshots when the combined set exceeds the
retention limit. Add a regression test covering the shutdown-growth case and
verifying the compacted window is preserved.

If SubmitBatch() fails inside the items == CHUNK_ITEMS branch, this line drops pending.writes up to write_it before restoring state, which removes the currently failing chunk as well. In a boundary case (for example, 4 pending writes with CHUNK_ITEMS=2 and the second batch failing), the uncommitted keys from that failed batch are permanently lost instead of being retried.

On a batch failure in the erase loop, this code erases pending.erases through next before restoring, which also removes erase intents from the failed chunk. If failure happens exactly on a chunk boundary (e.g., 4 queued erases with CHUNK_ITEMS=2, second erase batch fails), those keys are no longer queued and will remain on disk after retry.

When forced flush enters the compaction path (total_live_snapshots > LIST_CACHE_SIZE), RewriteSnapshotWindow calls ResetDB() before any replacement batches are durably written. If a later WriteBatch fails (disk/full I/O error), the function returns false after the existing persisted snapshot set has already been deleted, leaving the DMN snapshot DB empty or partially rebuilt. This is a destructive failure mode introduced by the new compaction logic; the reset needs to happen only after successful persistence of the replacement window (or via an atomic swap strategy).

ReadCache/ExistsCache now call MaybeFlushOnRead() before taking cs, which introduces a TOCTTOU window: another thread can run EraseCache and set bFlushOnNextRead after MaybeFlushOnRead() returns but before the read path acquires the lock, so the erase is not flushed and the code can return stale on-disk data that was just logically erased. I checked this against the LLMQ path where UndoBlock erases commitments (src/llmq/quorums_blockprocessor.cpp:280) while HasMinedCommitment/GetMinedCommitment read through ExistsCache/ReadCache (:349, :355), so this race can transiently resurrect reverted commitments.

After RewriteSnapshotWindow() has renamed the live DB to .rewrite-backup, it writes the compacted window via SubmitBatchForTesting(). In production this path calls WriteBatch(), which throws dbwrapper_error on LevelDB errors; because these calls are not wrapped in a try/catch, an exception skips restore_original() entirely and leaves the main DB path partially rewritten (or empty) while the valid data is stranded in the backup directory. Since there is no recovery path for *.rewrite-backup elsewhere in the repo, an I/O failure during forced flush can cause persisted DMN snapshots to be lost on restart.

When bFlushOnNextRead is set, this path now unlocks cs before calling FlushCacheToDisk(). In the new flush implementation, pending erases are moved out of shared state up front, so another thread can enter ReadCache/ExistsCache during that window, observe bFlushOnNextRead already cleared, and read stale data from LevelDB before the erase batch commits. This is a regression from the previous behavior where flush work stayed under the same lock and prevented that interleaving.

ForEachCachedEntry waits on m_read_flush_cv while using cs, but CDeterministicMNManager::DoMaintenance already holds m_evoDb->cs before calling this method (src/evo/deterministicmns.cpp, forced-flush path). With a recursive mutex, condition_variable_any::wait only unlocks one recursion level, so the outer DoMaintenance lock remains held; if another thread is in ReadCache/ExistsCache with m_read_flush_in_progress=true, it cannot reacquire cs to clear the flag and notify, causing a deadlock when forced maintenance overlaps an erase-triggered read flush.

MSG_BTCCSIG is introduced as a known inventory type (including IsKnownType), but CInv::GetCommand() in src/protocol.cpp still has no branch for it, so GetCommand() throws std::out_of_range for a valid type. This leaves inventory handling internally inconsistent and will trigger exception paths anywhere GetCommand() is used directly for BTCCSIG (debug/tooling today, and networking code paths as they evolve).

After RewriteSnapshotWindow() has renamed the live DB to .rewrite-backup, it writes the compacted window via SubmitBatchForTesting(). In production this path calls WriteBatch(), which throws dbwrapper_error on LevelDB errors; because these calls are not wrapped in a try/catch, an exception skips restore_original() entirely and leaves the main DB path partially rewritten (or empty) while the valid data is stranded in the backup directory. Since there is no recovery path for *.rewrite-backup elsewhere in the repo, an I/O failure during forced flush can cause persisted DMN snapshots to be lost on restart.

The rewrite path moves the live EvoDB directory to *.rewrite-backup before any compacted snapshot batch is durably written, so a process crash/power loss in the rewrite window can leave m_path containing only a partially rebuilt DB while the complete data sits in the backup directory that startup never restores automatically. In DoMaintenance forced-flush compaction, this can silently drop deterministic MN snapshots after an unclean shutdown; write into a temp DB and atomically swap only after success (or add startup recovery from the backup path).

After a successful compacting rewrite, this call drops the .rewrite-backup directory without checking whether it succeeded. If deletion fails (or the process stops before cleanup), RecoverRewriteBackupIfPresent will later treat that leftover backup as authoritative and replace the current DB with stale data on restart, potentially discarding snapshots that were just persisted during the rewrite. Please treat backup-cleanup failure as a real failure path instead of silently proceeding.

Recovery currently deletes db_params.path and only then attempts to rename the backup into place. If that rename fails (e.g., transient filesystem error or lock), the existing DB is already gone and startup continues with an empty freshly created DB, turning a recoverable backup issue into data loss. The replacement should be made atomic or rollback-safe so a failed rename cannot erase the active database.

The rewrite flow renames the live DB to *.rewrite-backup before creating *.rewrite-in-progress, so a crash/power loss between those two steps leaves only a backup directory; on restart, RecoverRewriteBackupIfPresent treats backup && !marker as stale and deletes it, which can drop the entire snapshot set and reopen an empty EvoDB. This affects any forced-flush compaction interrupted in that small window, and is a data-loss regression in the new crash-recovery path.

When startup recovery detects both backup and marker, it removes the marker even if fs::rename(backup_path, db_params.path, ec) failed. In that failure case, the next startup enters the has_backup-only branch and deletes the backup as "stale", which can discard the only intact snapshot set after an interrupted rewrite. Only clear the marker after a successful restore (or keep both artifacts for retry).

This startup cleanup deletes *.rewrite-backup whenever the marker file is absent, but WriteRewriteMarker only creates the marker with std::ofstream and never fsyncs it; after a power loss, it is possible to persist the directory rename (db -> backup) while losing the marker file. In that crash window, restart will treat the backup as stale and remove the only consistent snapshot set, causing silent data loss instead of recovery.

The recovery path unconditionally deletes the live EvoDB and restores *.rewrite-backup whenever both backup and marker exist. If the process crashes after all compacted batches were written but before RemoveRewriteMarker() runs, restart will hit this branch and roll back a fully written DB, dropping the newest snapshots that were just persisted during forced flush. This creates avoidable state regression after unclean shutdowns; recovery should distinguish "rewrite incomplete" from "rewrite complete but marker not cleaned" before deleting the live DB.

WriteRewriteMarker only calls std::ofstream::flush(), which does not durably commit the marker file to disk. If power is lost after the old DB is renamed to .rewrite-backup and the new DB rewrite has begun, the marker can be missing on restart even though a rewrite was in progress; RecoverRewriteBackupIfPresent then treats this as an unmatched backup and keeps the possibly partial live DB instead of restoring the backup. This can silently drop DMN snapshots after an unclean shutdown, so the marker write needs a durable fsync (and directory sync) or recovery should not trust a live DB when a backup exists without a complete marker.

fix: compact EvoDB DMN snapshots on forced flush

The RPC signature now advertises three optional arguments (btcprevhash, hash, auxpow), so a 3-argument call passes parameter checking, but the handler logic only branches on size == 0 || size == 1 for create and otherwise falls into the legacy submit path that reads params[0] as block hash and params[1] as auxpow. In practice, getauxblock(btcprevhash, hash, auxpow) misinterprets the arguments and ignores the real auxpow instead of handling (or rejecting) the call deterministically.

The createauxblock(address, btcprevhash) path accepts any string and feeds it directly to SetHex, which silently accepts partial/invalid hex and zero-fills the rest. At BTCPREV-required heights this can generate templates with malformed/null commitments that are guaranteed to fail consensus (bad-btcp-*) only after miners spend work, instead of rejecting the RPC request up front.

btcpRequired is computed from a tip snapshot taken before getCurrentBlock(...), but getCurrentBlock may rebuild the template on a newer tip if a block arrives in between. Around sign-offset boundaries, this can flip the requirement and cause the returned auxpow template to miss a required BTCPREV commitment (later rejected as bad-btcp-missing in contextual validation) or require one unnecessarily. This race is reachable whenever tip changes between these two steps.

Using CTxDestination(WitnessV0KeyHash(keyID)) here forces CWallet::SignHash to resolve signing data for a P2WPKH script, which can fail even when the voting key exists (for example, keys managed under legacy/pkh() paths). In that case gobject_vote_many/gobject_vote_alias now return signing failures for valid masternode voting keys, whereas the previous direct-key path worked regardless of address encoding.

Clreceipt

Reject CLSIGs whose candidate block diverged before the previous sign-window
anchor on the active chain.

This closes the deep private-fork salvage case where a minority branch at the
current signing height could be chainlocked even after the network had moved on
well past its fork point. The new check is fully chain-derived, so it does not
depend on in-memory ChainLock state surviving restart or propagation gaps.

Add functional coverage that asserts deep-diverged current-height chainlocks are
rejected with clsig-window-ancestor-mismatch and that nodes stay on the longer
local branch until normal chain-work later wins.

fix: Bound ChainLocks reorgs to one sign window

add blake2s DA hash, with zkSYS this will be a 500x improvement (reduction of circuit size and risc v cycles for DA commitments). 9 blobs of KZG = ~540m, wrt keccak ~160m, wrt blake2s ~300k.

Use b2s256 from relic as optimized implementation. Benchmarks show it to be 4x faster than keccak/sha256.

This change introduces a new external symbol dependency (md_map_b2s256) in nevm/sha3.cpp, but only some link targets were updated to place $(LIBDASHBLS) after $(LIBNEVM). I checked the Qt link lines and they still have $(LIBDASHBLS) before $(LIBNEVM) (src/Makefile.qt.include:339-341, src/Makefile.qttest.include:57-60), which is order-sensitive for static archives and can leave md_map_b2s256 unresolved when ENABLE_QT is on.

Adding hash_type as argument index 2 breaks existing positional callers that previously passed conf_target in that slot (for example ... 6 economical 25), because this code now unconditionally treats param 2 as a string hash type and rejects numeric values with RPC_INVALID_PARAMS. The same regression pattern is present in both blob creation RPCs, so existing automation/scripts will fail after upgrade unless they are rewritten to include hash_type explicitly.

Moving conf_target/fee_rate conversion to indexes 3/5 causes syscoin-cli legacy positional calls (e.g. ... "data" true 6 economical 25) to send argument 2 as a raw string, because only indexed entries in vRPCConvertParams are JSON-parsed (RPCConvertValues uses ArgToUniValue by index). In this commit, the wallet handlers treat string param 2 as hash_type and reject values like "6", so existing scripts for both syscoincreaterawnevmblob and syscoincreatenevmblob now fail instead of following the intended “legacy positional compatibility” path.

Move DMN EvoDB maintenance out of the shutdown rewrite path and keep the authoritative 1728-snapshot window pruned on disk during post-IBD flushes. Shrink the hot in-memory cache to 128 after initialization so older quorum lookups still work via disk fallback without the shutdown RAM spike.

In Chainstate::FlushStateToDisk, dmn_window_init_needed is keyed only on !HasPersistentWindow(), so on chains/heights before DIP0003 activates this stays true forever (no DMN snapshots exist yet, so the flag never flips). That forces the if (fDoFullFlush || fPeriodicWrite || dmn_window_init_needed) path on every periodic call, causing repeated block-index/DB flush work even when nothing else requires it. This is a performance regression for pre-DIP contexts (notably regtest/new deployments) introduced by the new bootstrap trigger.

Evodb prune retake

feat: BitcoinDA - blake2s

Auto-source btcprevhash from the configured BTC header backend on BTCPREV-required heights (including policy-on-demand), and fail closed when the backend is unavailable or still in IBD. Also align getauxblock submit arg ordering with miner compatibility and extend tests for BTCPREV template regeneration and btcheader-backed createauxblock autofill.

The startup requirement now triggers whenever a miner fee-recipient flag appears in -gethcommandline, but this check runs before -hrp handling later disables NEVM (fNEVMConnection = false). In a run configured with -hrp (testing mode) plus a leftover miner flag, the node can abort on missing BTCC backend even though NEVM is intentionally disabled in the same init path, which is an avoidable startup regression introduced here.

Because we can update template based on BTC prev hash changing we need to do away with try_emplace which will not update if scriptID exists, the scriptID in the cases where BTC prev hash updates is not expected to change, therefor we should replace the curBlocks mapping to the new block with injected BTC hash.

By setting init_btcheader_backend from btcheader_policy_active_chain, startup now runs BTC header backend initialization on essentially every non-mine-blocks-on-demand chain, even when the node is neither a masternode nor NEVM miner-configured. This introduces new startup overhead and backend-failure/logging paths for ordinary nodes that never use auxpow creation RPCs, which is a broad behavior regression from the previous role-gated initialization.

require_btcheader_backend is derived from fNEVMConnection before DoGethStartupProcedure() runs, but DoGethStartupProcedure() can later set fNEVMConnection = false. In that case, the node can still hit the hard failure at startup based on the stale precomputed requirement, so a non-masternode with miner fee-recipient flags may abort on missing btcheader backend even after NEVM was already disabled. This makes startup behavior depend on outdated state and should be gated on the post-startup NEVM status.

createAuxBlock() decides whether to auto-fetch btcprevhash using a height snapshot, then later getCurrentBlock() recomputes sign-offset requirements from the (possibly newer) tip. If the tip advances between these two checks to a sign-offset height, no autofill is attempted and the later path throws "btcprevhash is required at this height", causing intermittent RPC failures when callers omit btcprevhash even though a btcheader backend is configured. The requirement check and autofill need to be based on the same final height decision.

This branch now treats any single non-null argument as btcprevhash, but createauxblock passes the payout address as its only positional argument when btcprevhash is omitted. As a result, a normal call like createauxblock("<valid address>") now runs through ParseHashV(..., "btcprevhash") and fails with a length/hex error instead of creating a block template, which breaks the documented optional-btcprevhash flow for callers that don't provide a second argument.

AppInitMain adds nevm_enabled_for_mining_checks but never reads it, which triggers -Wunused-variable under normal warning flags; in this repo, CI jobs that pass --enable-werror (for example ci/test/06_script_a.sh and ci/test/06_script_b.sh) promote that warning to a hard error, so this change can break compile/test pipelines even though runtime behavior is unchanged.

Mining headernode

Require aggregate-shaped signer sets before trusting cached verification results so share cache entries cannot substitute for aggregate BLS verification.

Co-authored-by: Cursor <cursoragent@cursor.com>

Wait for the receiving node's active height window before submitting the recovered ChainLock so the test does not race the height gate.

Co-authored-by: Cursor <cursoragent@cursor.com>

Harden LLMQ aggregate signature cache checks

Remember peer-delivered ChainLock and BTC checkpoint objects that reach BLS verification and fail so repeated announcements do not trigger repeated signature work.

Co-authored-by: Cursor <cursoragent@cursor.com>

Only score peer-delivered invalid CLSIGs when processing reached signature verification, avoiding penalties for transient missing quorum context.

Co-authored-by: Cursor <cursoragent@cursor.com>

Cache rejected LLMQ signature messages

llmq: fix early-return signer comparison in quorum commitment handling

Initialize BufferedFile type to avoid uninitialized serialization flags

Move wallet-controller-dependent action connections out of createActions() so Qt receives a valid controller context and can still auto-disconnect on teardown.

Co-authored-by: Cursor <cursoragent@cursor.com>

qt: auto-disconnect wallet menu/action lambdas on controller teardown

test: avoid mutating const chain params in auxpow test

shutdown: avoid early-signal crash before kernel context init

fuzz: fix process_message per-target message type mapping

wallet: avoid out_of_range when bump fee map is incomplete

evo: make NEVM diff emission order deterministic

Separate external NEVM disconnect verification from local special transaction state updates so startup rollback can repair quorum cache without touching geth.

Co-authored-by: Cursor <cursoragent@cursor.com>