. #35748

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>

validation: keep local undo during NEVM startup rollback

Fix data race in CQuorum::SetSecretKeyShare

Keep configure-time getrandom detection aligned with random.cpp so Linux builds use the intended OS entropy path.

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

build: restore getrandom feature detection

Keep minted NEVM transaction records durable because they enforce consensus-critical uniqueness and do not have a crash replay marker.

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

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

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

validation: avoid refreshing duplicate PoDA blob metadata

Reject malformed mint log topics before decoding the indexed asset GUID so validation cannot read past the RLP topic buffer.

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

Preserve log scanning behavior by skipping non-freeze topic lists before enforcing the freeze-event topic shape.

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

validation: harden width

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

Avoid TOCTOU-triggered block read failure in FillNEVMData

Validate the downloaded or cached macOS SDK archive before extraction so containerized Guix builds do not silently trust tampered SDK inputs.

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

net: cap non-transaction inventory relay per send cycle

guix: verify macOS SDK archive

This reverts commit 135ffaef4ee8083ef2da8e22bd17a24ecc381e30.

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

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

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

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

Move duplicate metadata refresh coverage out of the chainlock-heavy functional path and add focused unit tests for auxiliary-data classification and metadata refresh rules.

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

When stale mempool metadata is superseded by a block-owned cache entry, keep the blob and immediately persist the newer metadata so disk and cache remain consistent.

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

Use metadata reads directly where the value is needed so cache and disk handling does not branch on stale existence checks.

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

Use the invalid-block path for malformed auxiliary PoDA sidecars without marking the committed block hash permanently failed.

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

validation: avoid invalidating blocks on PoDA sidecar mismatch

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

Remove privileged pull_request_target execution so untrusted PR code cannot access GHCR package credentials, and scope workflow permissions to the jobs that need them.

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

Use the narrower ptrace capability for ASan CI instead of privileged container access with a writable kernel mount.

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

validation: verify supplied PoDA sidecars

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

Keep queued script validation work bounded by its referenced transaction data when block connection exits through validation failure paths.

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

validation: drain script checks before block failure returns

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

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

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

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

nevm: avoid managed geth startup and shutdown stalls

add doc BTC-header-backend.md

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

Keep the long sysgeth wait only for a live state bootstrap, remove the unshipped EvoDB rewrite marker leftovers, and add missing BTCC lock annotations.

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

Use a two-hour default for active state bootstrap instead of preserving the old four-hour startup budget.

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

Drop tests for the unshipped RewriteSnapshotWindow marker recovery path now that EvoDB maintenance relies on incremental pruning and reindex recovery.

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

Harden managed geth bootstrap startup

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

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

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

Harden managed geth ZMQ handling

Bound BTCC/BTCPREV tagged-tail parsing to the maximum serialized payload size and avoid per-candidate suffix copies while preserving ambiguity rejection.

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

Fix BTCC receipt tail parsing DoS

Reject non-canonical asset allocation commitments after CL receipt activation so bridge burns and mints cannot rely on ambiguous asset/output mappings.

Validate authenticated mint fields and canonical burn commitments at the bridge boundary while preserving pre-activation behavior and rejecting malformed proof structures safely.

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

Serialize first-winner publication with chain-state revalidation and prevent stale alternative targets from consuming quorum signing attempts.

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

Make the signing candidate satisfy the active anchor first so the test specifically proves rejection of a non-ancestor lower winner.

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

Only follow a competing signing target when both branches derive the same DKG-base ancestry, preventing signatures under a quorum vector from the wrong branch.

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

Prevent reorged commitment caches and alternative branches from making ChainLock quorum interpretation depend on node history.

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

Close reorg races in signature caching, local signing, and quorum cache publication while preserving first-share convergence.

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

Track the active block at the signing height so ordinary tip extensions do not invalidate an otherwise stable quorum context.

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

Allow peers to reannounce a valid ChainLock after a transient quorum-context rejection.

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

Cover production quorum construction, stale same-base eviction, and replacement cache reuse instead of preloading both cache entries.

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

Align the functional RPC expectation with commitment-aware quorum ancestry by rejecting a signing height at the DKG base before its final commitment exists.

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

Include the lock declaration required for Clang thread-safety analysis so sanitizer builds compile the new quorum-context contract.

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

Harden ChainLock publication and signing

Harden asset allocation bridge validation

Reconstruct the same current and prior quorum sets used during signing after commitment-ancestry filtering.

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

Only clear the NEVM mint-replay database on -reindex /
-reindex-chainstate, not when reconstructible NEVM auxiliary
databases are reinitialized during a continued reindex.

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