Repository navigation
docs: add v24.0.0 release notes and archive v23.1.8 and v23.1.9 - #7970
Merged
PastaPastaPasta merged 8 commits intoOct 30, 2026
Merged
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…iles Fold every doc/release-notes-*.md fragment on v24.0.x into the v24.0.0 major-release notes, add the network upgrade, compatibility and downgrade sections, reference Bitcoin-numbered fragments by their Dash backport PR, and delete the fragments. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add missing PR references for the -rescan and --enable-gprof removals, restore the deprecation history of the top-level mempool fee fields, and give the shared-masternode subsections unique headings. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Collaborator
|
🕓 Review not started yet because the new head is waiting for the 30-minute push debounce.
Commit 5800e5d. Normal review starts when eligible; priority review starts as soon as a slot is available. |
thepastaclaw
left a comment
thepastaclaw
left a comment
Collaborator
There was a problem hiding this comment.
Final review — Phase 1 only (trivial change)
The documentation changes are generally accurate and the supplied code checks found no blocking implementation issue. Four non-blocking issues remain: one release-note claim depends on #7965 landing first, two Older releases links are dead, and one review-fix commit should be squashed into the notes commit.
🟡 2 suggestion(s) | 💬 2 nitpick(s)
Review provenance
Source: reviewer 1: glm-5.3-flash (agent: phase1-reviewer, role: general); reviewer 2: glm-5.3-flash (agent: phase1-reviewer, role: dash-core-commit-history); final verifier: gpt-6.1-sol (agent: sol-gate-verifier, role: final-verifier)
- Triage:
trivialbygpt-6.1-sol(effort low) — This pull request only reorganizes and adds release-note documentation without changing source code, build configuration, or runtime behavior. - Phase 1 reviewers:
glm-5.3-flash— general (completed, effort high); agentphase1-reviewer,glm-5.3-flash— dash-core-commit-history (completed, effort high); agentphase1-reviewer - Phase 1 model:
glm-5.3-flash— zai quota: 5h 97% left, weekly 89% left; passed overgemini-3.8-flash-high(antigravity quota lookup failed) - Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-gate-verifier - Phase 2 reviewers: not run (triage rated this change trivial); this review comments and never approves
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `doc/release-notes.md`:
- [SUGGESTION] doc/release-notes.md:545-547: The v23.1.9 negative-nVersion claim depends on #7965 landing first
The v24.0.x base does not contain the negative-transaction-nVersion consensus rule: the relevant check is present in the v23.1.9 lineage but is absent from the current branch. Because the PR description declares #7965 as a dependency, this is a merge-order constraint rather than a code defect, but merging this PR first would publish release notes describing a rule that the binary does not yet enforce. Make the dependency explicit in the wording or merge #7965 before this change.
- [NITPICK] doc/release-notes.md:975: The v0.15.0.0 Older releases entry links to a nonexistent file
The archived file is named `release-notes-0.15.0.md`, not `release-notes-0.15.0.0.md`, so this newly added Older releases link resolves to a nonexistent document. The date also contains the typo `Febrary`.
- [NITPICK] doc/release-notes.md:993: The v0.12.1 Older releases entry links to a nonexistent file
There is no `doc/release-notes/dash/release-notes-0.12.1.md` in the archive, so this newly added link is dead. Either remove the v0.12.1 row or point it to an existing archived release-note document representing that release series.
- [SUGGESTION] doc/release-notes.md:1: Squash the review-fix commit into the notes commit
Commit `3bbe3e23100` only amends the release-notes document introduced by `28c39fc4ad2`; the notes were never shipped in their pre-fix form. Folding this review-fix commit into the commit that introduced the document would avoid artificial review-response history and produce cleaner blame for the release notes.
Comment on lines
+545
to
+547
| - This release includes the fixes shipped in Dash Core v23.1.9, including the | ||
| consensus rule that rejects transactions with a negative `nVersion` once DIP3 | ||
| is active. |
Collaborator
There was a problem hiding this comment.
🟡 Suggestion: The v23.1.9 negative-nVersion claim depends on #7965 landing first
The v24.0.x base does not contain the negative-transaction-nVersion consensus rule: the relevant check is present in the v23.1.9 lineage but is absent from the current branch. Because the PR description declares #7965 as a dependency, this is a merge-order constraint rather than a code defect, but merging this PR first would publish release notes describing a rule that the binary does not yet enforce. Make the dependency explicit in the wording or merge #7965 before this change.
Suggested change
| - This release includes the fixes shipped in Dash Core v23.1.9, including the | |
| consensus rule that rejects transactions with a negative `nVersion` once DIP3 | |
| is active. | |
| - This release is expected to include the fixes shipped in Dash Core v23.1.9, including the | |
| consensus rule that rejects transactions with a negative `nVersion` once DIP3 | |
| is active. |
source: glm-5.3-flash (phase1-reviewer: general, dash-core-commit-history)
| - [v0.16.1.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.1.1.md) released November/17/2020 | ||
| - [v0.16.1.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.1.0.md) released November/14/2020 | ||
| - [v0.16.0.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.16.0.1.md) released September/30/2020 | ||
| - [v0.15.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.15.0.0.md) released Febrary/18/2020 |
Collaborator
There was a problem hiding this comment.
💬 Nitpick: The v0.15.0.0 Older releases entry links to a nonexistent file
The archived file is named release-notes-0.15.0.md, not release-notes-0.15.0.0.md, so this newly added Older releases link resolves to a nonexistent document. The date also contains the typo Febrary.
Suggested change
| - [v0.15.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.15.0.0.md) released Febrary/18/2020 | |
| - [v0.15.0.0](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.15.0.md) released February/18/2020 |
source: glm-5.3-flash (phase1-reviewer: general, dash-core-commit-history)
| - [v0.12.2.3](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.3.md) released Jan/12/2018 | ||
| - [v0.12.2.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.2.md) released Dec/17/2017 | ||
| - [v0.12.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.md) released Nov/08/2017 | ||
| - [v0.12.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.1.md) released Feb/06/2017 |
Collaborator
There was a problem hiding this comment.
💬 Nitpick: The v0.12.1 Older releases entry links to a nonexistent file
There is no doc/release-notes/dash/release-notes-0.12.1.md in the archive, so this newly added link is dead. Either remove the v0.12.1 row or point it to an existing archived release-note document representing that release series.
Suggested change
| - [v0.12.1](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.1.md) released Feb/06/2017 | |
| - [v0.12.2](https://github.com/dashpay/dash/blob/master/doc/release-notes/dash/release-notes-0.12.2.md) released Nov/08/2017 |
source: glm-5.3-flash (phase1-reviewer: general, dash-core-commit-history)
| @@ -1,10 +1,10 @@ | |||
| # Dash Core version v23.1.8 | |||
| # Dash Core version v24.0.0 | |||
Collaborator
There was a problem hiding this comment.
🟡 Suggestion: Squash the review-fix commit into the notes commit
Commit 3bbe3e23100 only amends the release-notes document introduced by 28c39fc4ad2; the notes were never shipped in their pre-fix form. Folding this review-fix commit into the commit that introduced the document would avoid artificial review-response history and produce cleaner blame for the release notes.
source: glm-5.3-flash (phase1-reviewer: general, dash-core-commit-history)
thepastaclaw
added
the
pastaclaw:commented
Fold in doc/release-notes-7861.md (pruning keeps 2304 blocks), which landed on v24.0.x after these notes were drafted, and document changes from the v23.1.9..v24.0.x range that the notes missed: - breaking: -txindex=0 now requires -disablegovernance (dashpay#7785), -deprecatedrpc=exclude_coinbase removed (dashpay#7492), rescanblockchain needs an unlocked wallet (dashpay#7711), per-element -rpcwhitelist batch checks (dashpay#7722), ProTx version 3 wire format and EvoNode ExtAddr rules (dashpay#7302, dashpay#7741, dashpay#7748, dashpay#7751), multiplicity-correct coinbase payment matching (dashpay#7362, dashpay#7377), mandatory script flag reject reason (dashpay#7710), system time for block validation (dashpay#7430) - How to Upgrade: index-flag continuity (dashpay#7745), -txindex/governance, pruning depth - RPC/REST/wallet/GUI items: scanblocks, getrawtransaction verbosity, generateblock submit, masternode status quorumParticipation, quorum dkgstatus semantics, index-syncing errors, REST mempool parameters, dash-wallet -legacy, stale fee estimates, importwallet on pruned nodes, hybrid keys, mixing-only unlock no longer signs PSBTs, shared_combine registrar checks, P2P penalties and spork announcements, SHA-256 acceleration, Asset Lock history rows, Migrate Wallet menu, splash screen, coin control and options moves Fix inaccuracies: _legacy RPCs never accept a payouts array while register_prepare(_evo) do, descriptorprocesspsbt does not exist in Dash, dashpay#7858 already shipped in v23.1.9, the Bitcoin Core coverage claim, and the stale devnet-reset note. Credit only people who contributed to Dash Core directly, and fix the dead v0.15.0.0 and v0.12.1 archive links. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
thepastaclaw
removed
the
pastaclaw:commented
The "Extended addresses (ProTx version 3)" section mixed two features that only share a transaction version. Split it into a neutral "Provider transaction version 3 format" note (wire-format change, v3 for ProUpRegTx/ProUpRevTx, folded-in v4, parser impact) and an "Extended addresses" section (netInfo, EvoNode ProUpServTx v3 requirement, port 443). Both features activate with v24; extended addresses do not depend on evo_shares, while EvoNode shares and multiple payouts do. The shared masternode section now points to the format note instead of calling version 3 "extended addresses". Restate Bitcoin Core backport coverage per release: essentially all of v0.17-v24, about 90% of v25, 70% of v26, over half of v27 and a third of v28. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The release notes said the two sporks were "effectively always enabled" on mainnet, which reads as if they could have been switched off there. Mainnet spork values have been hardcoded since v21.0.0 (dashpay#6140), so only the test networks still honored them; dashpay#7278 removes the definitions and that remaining test-network gating. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3 tasks done
PastaPastaPasta
pushed a commit
to PastaPastaPasta/dash
that referenced
this pull request
Nov 2, 2026
…c onion service unless -listenonion=1 8274f68 fix(net): restore the default onion bind as a best-effort listener (pasta) f2b78d3 fix(net): don't refuse to start over the automatic onion service unless -listenonion=1 (pasta) Pull request description: ## Issue being fixed or feature implemented Since dashpay#7786 (shipped to v24.0.x for rc.3 via dashpay#7808), a node with `-bind` but no `-bind=<addr>:<port>=onion` refuses to start while `-listenonion` is enabled. `-listenonion` is on by default, so this breaks every node with `bind=` and no Tor that worked on v23: dashmate evonodes, docker setups, hosts with several masternodes. It also hits 54 of DCG's 88 testnet hosts. The startup errors came from a partial backport of bitcoin#36170, which is still open upstream; released Bitcoin Core does not refuse to start here. Breakage matrix, develop / v24.0.0-rc.5 vs v23: | | Setup | rc.5 | v23 | |---|---|---|---| | S1 | `-bind`, no Tor, default `-listenonion` | refuses to start | starts | | S2 | `-bind`, zero-config Tor, default `-listenonion` | refuses to start | starts, onion service on the dedicated `127.0.0.1:9996` listener | | S3 | wildcard `-bind=0.0.0.0:P=onion`, `-listenonion` effective | refuses to start (kept by this PR) | starts, but Tor was pointed at a wildcard, which never worked, and Tor peers reaching it were treated as clearnet | | S4 | no `-bind`, default onion port already taken (e.g. a second instance with `-port`) | refuses to start, even with `-listenonion=0` | starts with a warning | The privacy fix from dashpay#7786 has to stay: Tor must never be pointed at a listener that isn't tagged as onion. Otherwise Tor-forwarded peers are treated as clearnet peers and are told the node's clearnet address. Before dashpay#7786, dashpay#7300 (backport of bitcoin#22729) caused exactly that by targeting the first `-bind`. The rule this PR implements: only an explicit `-listenonion=1` may turn a missing or unusable onion listener into a startup failure. The default `-listenonion` means "use Tor if it is there" (bitcoin#6639). The one exception is a wildcard `=onion` bind (S3). Writing `=onion` is explicit Tor intent, and a wildcard listener can't honor it: an accepted socket reports its concrete local address, which never matches the wildcard entry in `m_onion_binds`, so peers that Tor forwards there would be treated as clearnet and could be told our clearnet address. So while `-listenonion` is effective, default or explicit, any wildcard `=onion` bind, including one next to a specific bind, is a startup error with the existing message, as on rc.5 and in bitcoin#36170. With `-listenonion=0` it is accepted, as in v23 and released Bitcoin Core. Setups without Tor don't write `=onion`, so S1 always starts. ## What was done? Two commits. The second can be dropped on its own if reviewers prefer. **1. `fix(net): don't refuse to start over the automatic onion service unless -listenonion=1`** (fixes S1 and S2 at startup) - The `TorController` target is now `std::optional<CService>`. Without a target, Tor control still authenticates and runs `GETINFO net/listeners/socks` (outbound onion proxy discovery), but skips `ADD_ONION`. Once authenticated, it logs once that no onion service is created because there is no dedicated onion bind. Without Tor, the control-port connect just fails, as on v23. - In init, with `-listenonion` effective: - any wildcard onion bind: the existing wildcard `InitError`, default or explicit; - no onion bind and explicit `-listenonion=1`: the existing "requires a dedicated onion bind" `InitError`; - no onion bind and the default `-listenonion`: Tor control starts without a target. **2. `fix(net): restore the default onion bind as a best-effort listener`** (fixes S2 and S4 fully) - The default onion bind `127.0.0.1:<OnionServiceTargetPort>` is added again when there is no `=onion` bind and `-listenonion` is effective, even with `-bind`, as on v23 (the rule from dashpay#7786's first two commits). It is still added when there are no binds at all, for manual-torrc setups. With `-bind` and `-listenonion=0` it is not added. - Failing to bind it only logs a warning; explicit `-bind`, `-whitebind` and `=onion` failures stay fatal. With an explicit `-listenonion=1`, the default onion bind is required and its failure is fatal. That happens inside `InitBinds`, before network threads start. - A failed default onion bind is dropped from `CConnman`'s onion binds. Tor control now starts after `connman->Start()` and gets the target only if `CConnman::HasOnionBind()` still has it; otherwise it runs without a target. This avoids v23's misroute, where Tor forwarded to whatever held the port: another instance, or the node's own `-bind`/`-whitebind` on that address. Nothing between the old and new `StartTorControl` call sites depends on Tor control; onion proxy discovery was already asynchronous. - `p2p_permissions.py` gives its whitebind-only node a per-node onion bind, and the test framework's `p2p_port()`, `rpc_port()` and `tor_port()` never return the fixed regtest onion port `19896` (it is moved to the last port of its range, which no seed uses). `feature_bind_extra.py` and `interface_zmq.py` now get each extra port from `p2p_port()` instead of adding to one. That makes `feature_bind_extra.py` the only test binding `19896`, for every port seed and in parallel `test_runner.py` runs. Docs: the `-bind` and `-listenonion` help, `doc/release-notes-7300.md` (the v24 note that said such nodes "now refuse to start") and `doc/tor.md` describe the new behavior. Translated strings are unchanged. Commit 2 no longer uses the "requires a dedicated onion bind" message. Related: dashpay#7786, dashpay#7300, dashpay#7808, bitcoin#36170 (still open upstream), bitcoin#22729. ## How Has This Been Tested? Linux x86_64, `--enable-debug` build. - `feature_bind_extra.py`, which checks the node's actual listening sockets. Node 2 (`-bind` without an onion bind) is restarted with the framework's `listenonion=0` removed, so it runs with the default `-listenonion`: - commit 1: it starts and listens only on its `-bind`; - commit 2: it starts and also listens on the default onion target `127.0.0.1:19896`; - commit 2, with `127.0.0.1:19896` held by another socket: it still starts and listens only on its `-bind`, while an explicit `-listenonion=1` fails with the bind error; - a wildcard onion bind with the default `-listenonion` is the wildcard startup error, and with `-listenonion=0` it starts; - node 2's initial start sets `-listenonion=0` explicitly in commit 2, which checks that no default onion bind is added in that case. - Ran with both commits: `feature_bind_extra.py feature_proxy.py p2p_permissions.py interface_zmq.py rpc_bind.py feature_discover.py`, all pass (`rpc_bind.py --ipv6` skips on this host), also with `--portseed=8428` and in parallel with `TEST_RUNNER_PORT_MIN=19870`. Earlier revisions with the same `src/` also passed `rpc_net.py p2p_eviction.py feature_config_args.py p2p_addr_relay.py`, `test_dash --run_test=torcontrol_tests,net_tests,net_peer_eviction_tests`, `lint-whitespace.py` and `lint-python.py`. `check-doc.py` reports undocumented `-statsport` and `-printcrashinfo`, identically on develop. - Mutation checks, each failing `feature_bind_extra.py`: - develop's `src/`: node 2 refuses to start with the default `-listenonion`; - commit 1's `src/` under commit 2's test: no listener on `127.0.0.1:19896`; - the default onion bind made fatal again: node 2 doesn't start while the port is held; - the wildcard check removed: the node starts with a wildcard onion bind. - Commit 1 alone builds, and `feature_bind_extra.py feature_proxy.py p2p_permissions.py` pass at that commit. - Not covered by a functional test: which listener the automatic onion service is told to forward to (that would need a fake Tor control port), and that peers on our own non-onion listener at `127.0.0.1:19896` aren't treated as onion peers. Both were checked during development with a test that is no longer part of the PR. ## Breaking Changes Compared with v24.0.0-rc.1 to rc.5, none. Nodes that failed to start now start. Compared with v23: - a wildcard `=onion` bind is a startup error unless `-listenonion=0` is set; - if the default onion bind fails, no onion service is created, rather than pointing Tor at whatever holds the port; - an explicit `-listenonion=1` without a usable onion bind is a startup error; - `-bind` with `-listenonion=0` no longer binds the default onion port (from dashpay#7300). ## Checklist: - [x] I have performed a self-review of my own code - [x] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone 🤖 Generated with [Claude Code](https://claude.com/claude-code) Top commit has no ACKs. Tree-SHA512: 5218897911c4dd8a1c4f7b5d0228f869f6ad654cfd8fd06a97462e82ffd2a3e52ba192acfda75dfe04f7b1f56c4b8f985d021df0df3766c9b1d1bce46a341865 [v24.0.x: doc/release-notes-7300.md was folded into doc/release-notes.md for v24.0.0 (dashpay#7970), so its hunk is applied there in the next commit.] (cherry picked from commit 92f2bfb)
PastaPastaPasta
added a commit
that referenced
this pull request
Nov 2, 2026
914c052 docs: add #8003 to the v24.0.0 release notes and man pages (pasta) e81c511 Merge #8003: fix(net): don't refuse to start over the automatic onion service unless -listenonion=1 (merge-script) 41b4578 ci: run cppcheck as test/lint/cppcheck-dash.py, as develop does since #7966 (pasta) c97f3b3 docs: regenerate man pages for v24.0.0-rc.6 (pasta) 784312c docs: add the v24.0.0-rc.6 changes to the v24.0.0 release notes (pasta) f15a53a Merge #7991: fix(qt): shared masternode wizard fixes for taken shares, unconfirmed funding and reply handling (merge-script) 1c46224 Merge #7995: fix(wallet): don't let a waiting CoinJoin promotion/demotion queue block standard mixing (merge-script) 546db2f Merge #7996: fix(wallet): fill a CoinJoin promotion with sibling coins when needed (merge-script) 349859f Merge #7957: fix(qt): validate shared-masternode shares with the consensus rules (merge-script) 9091f0b Merge #8005: backport: bitcoin#27114, bitcoin#33395 (merge-script) e915ab5 Merge #7990: fix(wallet): pay for 3 byte input and output counts so 253+ input sends work (merge-script) Pull request description: ## Issue being fixed or feature implemented Backports and release prep for v24.0.0-rc.6, on top of `v24.0.x` at d693c69 (the v24.0.0-rc.5 tag 8163290 plus the 2026-10 translations, #7989). After this PR, rc.6 only needs tagging and building. ## What was done? Cherry-picked (`git cherry-pick -m1 -x`) every develop merge since rc.5 that carries `backport-candidate-24.0.x`, in develop merge order: - #7990 fix(wallet): pay for 3 byte input and output counts so 253+ input sends work - #8005 backport: bitcoin#27114, bitcoin#33395 - #7957 fix(qt): validate shared-masternode shares with the consensus rules - #7996 fix(wallet): fill a CoinJoin promotion with sibling coins when needed - #7995 fix(wallet): don't let a waiting CoinJoin promotion/demotion queue block standard mixing - #7991 fix(qt): shared masternode wizard fixes for taken shares, unconfirmed funding and reply handling (labeled for 24.0.x, milestone 24.1) - #8003 fix(net): don't refuse to start over the automatic onion service unless -listenonion=1 (picked after the CI commit below, once it merged) Every pick changes exactly the same lines as its develop merge, except for one test-only adaptation in #8005, described in its commit message, and #8003's `doc/release-notes-7300.md` hunk, which lands in `doc/release-notes.md` (that file was folded in for v24.0.0 by #7970). bitcoin#27114 makes `wallet_import_rescan.py` restart its pruned nodes with their real `-prune` arguments; before, the restart passed only `-whitelist`, so they never actually ran pruned. On develop, #7860 removed the governance-disabled warning that pruned nodes print to stderr. This branch doesn't have #7860, so the test failed at shutdown on the unexpected stderr. The pick now stops the pruned nodes at the end of `run_test` with `EXPECTED_STDERR_NO_GOV_PRUNE`, the way `feature_pruning.py` does. Release prep, in commits after the picks: - `doc/release-notes.md`: `doc/release-notes-27114.md` is folded in and removed, as rc.5 did with the other individual notes (#7970). Also added: #8005's change that address-based `-whitelist` permissions no longer apply to onion inbound peers, and the CoinJoin conversion behaviour from #7995 and #7996. #7990, #7957 and #7991 fix code that is new in v24, so they get no release note. - #8003's release-note change replaces the v24 bullet that said nodes with `-bind` and no onion bind "refuse to start", in a separate docs commit after the #8003 pick that also regenerates `dashd.1` and `dash-qt.1` for its `-bind`/`-listenonion` help. - `doc/man/*.1`: regenerated with `contrib/devtools/gen-manpages.py` from a build of this branch with `CLIENT_VERSION_IS_RELEASE` set temporarily (not committed), as in #7974. Every page reads `v24.0.0`. They pick up #8005's `-whitelist`, `-whitelistrelay`, `-whitelistforcerelay` and `-blocksonly` help changes, and the `-assumevalid` defaults from #7980, which merged after the v24.0.0 man pages were generated. One CI-only commit follows the first six picks. Pull requests into `v24.0.x` run develop's workflow files (`pull_request_target`), and since #7966 develop runs cppcheck in its own job as `test/lint/cppcheck-dash.py`. This branch still had `test/lint/lint-cppcheck-dash.py`, so that job failed with "No such file or directory". The commit takes only #7966's rename (the script is unchanged), which also keeps develop's lint job from running cppcheck a second time through `all-lint.py`. This branch's own `lint.yml` now calls the renamed script after `ci/dash/lint.sh`, so its push CI still runs cppcheck. The rest of #7966 (the ci-slim cppcheck build and the separate job) is left out. Nothing else needs to change for the tag: - `configure.ac` is already 24.0.0 with `CLIENT_VERSION_IS_RELEASE` false, so the build takes its version string from the `v24.0.0-rc.6` tag. - The 2026-10 translations are already on the branch (#7989). - `SECURITY.md` and the flatpak entry were done in #7972. ## How Has This Been Tested? Linux x86_64 against depends, `--enable-debug --enable-werror --disable-hardening`. `dashd`, `dash-qt`, `test_dash` and `test_dash-qt` build cleanly. - `make check`: all unit suites pass, and `test_dash-qt` passes (run with `QT_QPA_PLATFORM=minimal`). - Functional tests, all passing: every test #8005 touches that the runner lists (`feature_cltv.py`, `feature_csv_activation.py`, `feature_dersig.py`, `feature_fee_estimation.py`, `interface_rest.py`, `interface_zmq.py`, `mempool_packages.py`, `p2p_filter.py`, `p2p_invalid_block.py`, `p2p_permissions.py`, `rpc_packages.py`, `rpc_rawtransaction.py`, `wallet_abandonconflict.py`, `wallet_avoidreuse.py`, `wallet_backup.py`, `wallet_balance.py`, `wallet_basic.py`, `wallet_create_tx.py`, `wallet_fundrawtransaction.py`, `wallet_groups.py`, `wallet_hd.py`, `wallet_import_rescan.py`, `wallet_importdescriptors.py`, `wallet_listreceivedby.py`, `wallet_listsinceblock.py`, `wallet_listtransactions.py`, `wallet_send.py`), plus `feature_bind_extra.py`, `feature_masternode_shares.py` and `rpc_coinjoin.py`. - After the #8003 pick: `feature_bind_extra.py`, `feature_proxy.py`, `interface_zmq.py`, `p2p_permissions.py` and `torcontrol_tests` pass. #8003 changes the framework's port allocation, so the full non-extended functional suite was run as well: 313 passed, 12 skipped, 0 failed (`test_runner.py -j12` on a RAM disk). - `wallet_import_rescan.py --legacy-wallet` failed before the adaptation above and passes with it. - Each pick's changed lines were compared with its develop merge. - Checked that every `doc/man/*.1` reads `v24.0.0` with no rc, git hash or `-dirty` suffix. ## Breaking Changes Carried over from the picked PRs: - #8005: address-based `-whitelist` permissions no longer apply to peers that connect through the onion service. Before, an entry such as `-whitelist=noban@127.0.0.1` gave every Tor peer its permissions. `-whitelist` also accepts `in`/`out` flags, so its permissions can apply to manual outbound connections; the default is still incoming only. - #8003, relative to rc.5: nodes with `-bind` and no `=onion` bind start again, as on v23, and get the default onion bind unless `-listenonion=0` is set. If the default onion bind fails, the node starts without an onion service, unless `-listenonion=1` was set explicitly. A wildcard `=onion` bind is still an error while `-listenonion` is enabled; v23 accepted it. - #7990: in wallets with 253 or more spendable coins, changeless transactions pay for 2 more bytes of fee. - #7995: while a wallet still has coins to mix, it joins promotion/demotion queues that others opened, but opens its own only when it has no standard mixing session to join or start. ## Checklist: - [x] I have performed a self-review of my own code - [x] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone 🤖 Generated with [Claude Code](https://claude.com/claude-code) Top commit has no ACKs. Tree-SHA512: 2dfc830eb45d7fbd5d39066fcd9cdb783340b28f15ac5e78c85aedfb2d8eae7d42a1c291811a5ce8e899a675e1144324eda9dca8824108e236a514dbe0297a7e
3 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue being fixed or feature implemented
doc/release-notes.mdonv24.0.xstill contains the v23.1.8 notes, and 62doc/release-notes-*.mdfragments have piled up. Before v24.0.0-rc.5, the candidate for v24.0.0 final, they need to become one proper set of major-release notes. This follows the v23.0.0 precedent (#6932).What was done?
v23.1.9tag) underdoc/release-notes/dash/, and updated the "Older releases" list.release-notes-empty-template.mdis kept.PROTOCOL_VERSIONandMIN_MASTERNODE_PROTO_VERSIONraised to 70242.v24/evo_sharesschedule from backport: activate V24 on mainnet, signaling from November 9, 2026 (#7973) #7969 and the earliest activation height (block 2,580,480, around 2026-11-28). It also explains that v24.0.0 does not signevo_shares.-deprecatedrpc=serviceand-deprecatedrpc=softforks), descriptor wallets by default, async indexes, masternode configuration requirements, and provider transactions no longer being InstantSend-locked.DEPLOYMENT_V23#6729 note (no new legacy-scheme registrations and no basic-to-legacy downgrade after v24) was held back from v23.0.0 for v24 and later lost on develop. It is restored here because the rule is enforced on this branch.Dependencies:
How Has This Been Tested?
Documentation only.
test/lint/lint-whitespace.py,lint-files.pyand the spelling lint pass. Each fragment's claim was checked against the code onv24.0.x(option and RPC names, consensus rejection strings, protocol versions). A separate reviewer then re-checked the notes against the code.Breaking Changes
None (documentation only).
Checklist:
🤖 Generated with Claude Code