[PastaPastaPasta]

Issue being fixed or feature implemented

This gets develop ready for tagging v24.0.0-rc.1. Release candidates are tagged on develop itself, so develop needs to report 24.0.0 and testnet needs a concrete V24 signalling start time.

The scope is deliberately narrow. Mainnet deployment parameters will follow in a separate PR. MIN_MASTERNODE_PROTO_VERSION is in its own PR. Release notes, chain work/assumevalid, checkpoints and seeds are not touched here.

What was done?

1. configure.ac: 23.1.8 -> 24.0.0, _CLIENT_VERSION_IS_RELEASE stays false.
This follows the v23 precedent. f819f1b ("chore: bump develop to merging for v23") moved develop to 23.0.0, and v23.0.0-rc.1 was tagged with MAJOR 23 / MINOR 0 / BUILD 0 / IS_RELEASE false. Dash has no _CLIENT_VERSION_RC define: non-release builds take their version string from git describe (#5653), so the RC tag supplies the -rc.1 suffix.

I grepped for 23.1.8 / 230108 / CLIENT_VERSION_* to find anything else that carries the version. Nothing else needs to change in this PR:

• doc/Doxyfile.in, share/qt/Info.plist.in, share/setup.nsi.in and src/bitcoin-util-res.rc are substituted from the configure values automatically.
• contrib/guix gets its version from the git tag.
• CMakeLists.txt on develop is the IDE helper and carries no version.
• No test fixtures reference the version.
• doc/man/*.1 (v23.1.8) and contrib/flatpak/org.dash.dash-core.metainfo.xml are left alone on purpose. doc/release-process.md treats both as release-time steps, and at v23.0.0-rc.1 the man pages still said v22.1.0; they were regenerated for the final release (docs: update man pages for 23.0 #6928).

2. src/chainparams.cpp: testnet DEPLOYMENT_V24.nStartTime = 1790208000 (Thursday, September 24, 2026 00:00:00 UTC).
The format follows 15ba788 (#5567). nTimeout (NO_TIMEOUT), the 100-block window and the 80 -> 60 threshold are unchanged. Mainnet stays NEVER_ACTIVE with its TODO. Devnet and regtest are untouched.

This start time is a placeholder, and maintainers may want to move it. Every v24-gated consensus change still pending has to be merged and running on testnet nodes before activation.

What actually happens after the start time (EHF, useEHF = true)

• Signing. Nothing can happen until the testnet tip's median-time-past reaches nStartTime, which is roughly 6 blocks (~15 min) after the wall-clock time. From then on, CEHFSignalsHandler::UpdatedBlockTip sees that IsValidMNActivation(12, MTP) is in range and no bit-12 signal is known, so members of the LLMQ_50_60 quorum sign the bit-12 MnEHF request. The recovered signature becomes an MNHF_SIGNAL special transaction that miners include.
• Versionbits. Once that transaction is mined at height H, SignalHeight() returns H. The deployment moves DEFINED -> STARTED at the first 100-block period boundary at or after H. Miners then set bit 12, and the fork locks in once a full 100-block window has >= 80 signalling blocks. After the first window that threshold decays by n^2/5 per failed window, down to a floor of 60 after 10 windows. ACTIVE follows one window after LOCKED_IN. So the earliest activation is about 200-300 blocks (~8-12.5 h) after the signal is mined: a few hours after the start time at the very soonest.
• A bit-12 signal already exists on testnet. MnEHF tx d6220b5d9ca0318f24befcf0e6a748bb84836bd79efbdcf165867da638292220 sits in block 1349780 (MTP 2025-10-22). Today's nodes use nStartTime = NEVER_ACTIVE (-2), so IsValidMNActivation treats any time as in range and they accepted it. With this PR, CMNHFManager::GetSignalsStage marks that signal as expired because its MTP is before the new nStartTime, so v24 nodes need a new signal after the start time. I confirmed this on a copy of a synced testnet datadir running this branch offline. It logs mnhf signal bit=12 height:1349780 is expired, and getdeploymentinfo shows v24 as defined with start_time 1790208000.
• Consequence for non-upgraded testnet nodes. This part comes from reading the v23.1.8 code; I did not test it on a network. On v23.1.8 the old signal never expires, because signal_time < -2 is never true. So a block containing the new bit-12 MnEHF tx fails CMNHFManager::ProcessBlock there with bad-mnhf-duplicate. Old nodes therefore split off when the new signal is mined, soon after the start time, not at activation. Old miners skip the duplicate signal in block assembly and keep extending their own chain. In practice, testnet nodes (masternodes and miners in particular) need to run the RC before the start time, and that is one more reason to pick a date that leaves room after rc.1 is published.

How Has This Been Tested?

Tested on macOS arm64 (Darwin 25.5), ./configure --without-gui --disable-bench --disable-fuzz-binary against an existing depends prefix:

• make -j12 builds cleanly. Built with BITCOIN_GENBUILD_NO_GIT=1, src/dashd -version reports Dash Core version v24.0.0-unk, and bitcoin-config.h has PACKAGE_VERSION "24.0.0". With git build info the version string comes from git describe, so it only shows v24.0.0-rc.1 once that tag exists.
• src/test/test_dash --run_test=versionbits_tests,evo_mnhf_tests,argsman_tests passes (no errors).
• test/functional/test_runner.py feature_mnehf.py feature_versionbits_warning.py rpc_blockchain.py passes: feature_mnehf.py, feature_versionbits_warning.py, and rpc_blockchain.py under both v1 and v2 transport. These run on regtest, where the V24 params are unchanged, so they show that the EHF/versionbits machinery is unaffected. They do not exercise the new testnet value.
• I started this branch's dashd offline (-connect=0) on an APFS clone of a testnet datadir synced to height 1549291 and checked getdeploymentinfo, plus the expired-signal log line described above.
• test/lint/lint-whitespace.py passes. src/chainparams.cpp is not in test/util/data/non-backported.txt, so the clang-format CI job does not cover it; the comment column follows the existing alignment and the chore: v20 Testnet signaling starttime #5567 precedent.

Breaking Changes

Testnet only. After 2026-09-24 00:00 UTC, v24 masternodes on testnet will sign and mine a new bit-12 MnEHF signal, and testnet nodes running v23.x or older develop builds will reject the block that contains it (see above). Mainnet behaviour is unchanged. Apart from the version string, nothing else changes.

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 (for repository code-owners and collaborators only)

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[thepastaclaw]

⚠️ DEGRADED — Queued for automated review — 28th in line, estimated start in ~27 h (commit 22ff7e1)
Estimated review time once started: ~2.0 h (two-phase automated review; median of recent runs).
The primary review models are currently out of quota; this review will run on stand-in models and be marked as degraded.

• Request priority review — click to move this review to the front of the queue.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: f906943d-18ad-49a1-b805-a1d3388ea6b0

📥 Commits

Reviewing files that changed from the base of the PR and between e5de15a and 22ff7e1.

📒 Files selected for processing (2)

• configure.ac
• src/chainparams.cpp

Included review availability: Your plan provides up to 4 included reviews per hour; 1 remains after this review.

---

Walkthrough

The client version changes from 23.1.8 to 24.0.0. The testnet V24 deployment start time changes from NEVER_ACTIVE to 1790208000 (September 24, 2026).

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~8 minutes

Merge Risk: ⚪ Minimal · up to 22ff7

The change prepares the 24.0.0 release-candidate version and enables the scheduled testnet V24 path. Activation remains conditional on the existing EHF and miner-signaling process; no actionable merge risk is identified.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files. (1 skipped: 1 …	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The pull request title 'chore: bump to v24.0.0 and set testnet v24 start time' directly summarizes both main changes in the changeset: the version bump from 23.1.8 to 24.0.0 in configure.ac and the te…
Description check	✅ Passed	The pull request description is comprehensive and directly related to the changeset. It explains the issue (preparing develop for v24.0.0-rc.1), details what was done for each file modified (configure…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files. (1 skipped: 1 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[PastaPastaPasta]

approved