[PastaPastaPasta]

Issue being fixed or feature implemented

Backports #8131 to v24.0.x for v24.0.1, as its own PR so it can be reviewed and merged independently of #8128.

Inside a superblock's maturity window a masternode votes NO on every trigger that doesn't match its candidate and never revisits that vote. If the approved set changes while triggers are being created, masternodes can end up having voted NO on the trigger that matches their final candidate, and the superblock can go unpaid. #8131 makes a masternode wait for a trigger matching its own candidate before it votes NO on the others (until 3 blocks before the superblock), and clears the per-cycle "voted YES" marker by height so an unfunded cycle doesn't carry over into the next one.

Stacked on #8128, draft until it merges. This branch is #8128's branch plus three commits; only the last three belong to this PR. It has to sit on #8128 for CI to run at all: v24.0.x on its own can no longer fetch the miniupnpc sources for depends, which #8088 in #8128 fixes. It will be rebased onto v24.0.x once #8128 is in.

Depends on #8131. This PR should only be merged after #8131 has been reviewed and merged into develop. If #8131 changes during review, the picks here will be redone to match.

What was done?

• fix: wait for a matching superblock trigger before voting NO on the others #8131's two commits picked with git cherry-pick -x: the source change (src/governance/signing.{cpp,h}) and feature_governance_trigger_voting.py. Both apply without conflicts; signing.cpp on v24.0.x is identical to develop before the change.
• fix: keep governance triggers across a restart on test networks #8097 fix: keep governance triggers across a restart on test networks, picked with git cherry-pick -m1 -x, source change only (two lines in src/governance/governance.cpp). It is needed here: without it a masternode restarted inside the maturity window drops its stored triggers on regtest, testnet and devnets and then rejects the superblock, which is what the restart case of the new test does. Mainnet is not affected by that bug, because the expiry check involved is skipped there. fix: keep governance triggers across a restart on test networks #8097's own feature_governance.py step is left out because it restarts the pruned node added with feat: run governance on pruned nodes #7860, which v24.0.x doesn't have.

How Has This Been Tested?

On a v24.0.x build with these three commits on top of #8128's branch, macOS arm64, depends build with --enable-debug --enable-werror, no GUI:

• feature_governance_trigger_voting.py, feature_governance.py, feature_governance_cl.py and feature_governance_objects.py pass, 3 runs each.
• Without the fix: keep governance triggers across a restart on test networks #8097 source change, feature_governance_trigger_voting.py fails in its restart case: the restarted masternode rejects the superblock with bad-cb-amount.
• Unit tests governance* pass (32 cases).
• The full functional suite (test_runner.py -j16) on the same build: 310 passed, 17 skipped (the usual environment-dependent tests), none failed. That run was built before a one-token change to the source commit (int superblock_height{0};, a default member initializer cppcheck asked for); the governance tests above were not repeated on v24.0.x after it, the new test was re-run on develop.

#8131 describes the scenarios and how each was shown to fail without the change.

Breaking Changes

None. Behaviour change for masternodes: a NO vote on a non-matching trigger may be cast later than before, when the masternode's own candidate has no trigger yet, and at the latest 3 blocks before the superblock.

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone (if you have permission to set one)

🤖 Generated with Claude Code

[thepastaclaw]

✅ Final review complete — no blockers (commit c7efde2) · triage: critical

[thepastaclaw]

Final validation — Phase 1 + Phase 2

Static verification at c7efde2 found no actionable issues in the three commits belonging to #8132; the two supplied findings concern an explicitly excluded test and diagnostics owned by the #8128 stack. The failed amd64 slim-container job is unrelated to these changes: its log shows curl failing to connect to apt.llvm.org while downloading the repository key; lint/cppcheck were skipped and the multi-architecture manifest check remains pending. No builds or tests were run in this static-review lane.

Review provenance

Source: reviewer 1: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: backport-reviewer); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); reviewer 4: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: critical by gpt-6.1-sol (effort low) — The change is an intricate governance-signing behavior change in src/governance/signing.cpp that affects superblock trigger votes and therefore whether masternode-funded superblock payments occur.
• Phase 1 reviewers: muse-spark-1.3-contributor — general (completed, effort xhigh); agent phase1-reviewer
• Phase 1 model: muse-spark-1.3-contributor — not quota-gated; passed over gemini-3.8-flash-high (antigravity quota lookup failed), glm-5.3-flash (not used above high effort; tier asks max)
• Single stage: Phase 1 and Phase 2 reviewed this head side by side, with no blocker gate between them (triage tier)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — backport-reviewer (completed, effort xhigh); agent phase2-reviewer, gpt-6.1-sol — dash-core-commit-history (completed, effort xhigh); agent phase2-reviewer