Repository navigation
chore: update minimum masternode peer version - #7138
Merged
Merged
Conversation
PastaPastaPasta
approved these changes
Feb 13, 2026
PastaPastaPasta
left a comment
PastaPastaPasta
left a comment
Member
There was a problem hiding this comment.
ACK, the instantsend improvements are valuable enough to have MNs kindly force other MNs to upgrade.
WalkthroughThe pull request updates the minimum masternode protocol version constant in src/version.h from 70238 to 70240. This is a single-line change that aligns the minimum masternode protocol version with related version constants in the file. No logic modifications or functional changes are introduced. Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
No actionable comments were generated in the recent review. 🎉 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. Comment |
✅ No Merge Conflicts DetectedThis PR currently has no conflicts with other open PRs. |
UdjinM6
approved these changes
Feb 13, 2026
2 of 3 tasks
PastaPastaPasta
added a commit
that referenced
this pull request
Sep 22, 2026
f764147 chore: bump MIN_MASTERNODE_PROTO_VERSION to 70242 for v24 (pasta) Pull request description: ## Issue being fixed or feature implemented For v24, `MIN_MASTERNODE_PROTO_VERSION` needs to match the current `PROTOCOL_VERSION`. This follows the bump done for every major release (#5223 for v19, #6458 for v22, #7138 for 23.1). On `develop` the constant is still 70240 while `PROTOCOL_VERSION` is 70242. Both values were checked on `develop` at e5de15a. v24.0.0-rc.1 will be tagged on `develop`, so the bump has to land there first. It is split from the version / testnet-params PR on purpose. The operator-facing effect (see Breaking Changes) differs from a version-string or chain-params change, so it is easier to review, and to revert if it has to be, as its own PR. v24 masternodes need DKG peers at 70242 or newer because the two protocol versions added in this cycle are both v24 features: - **70241 `COINJOIN_REBALANCE_VERSION`** (#7052): CoinJoin denomination promotion/demotion (rebalance) sessions. `dsa` gains a version-gated flags field, and rebalance DSTXes are withheld from peers below 70241 (`CanAnnounceDstxTo`). Older peers would drop those DSTXes and penalize the relayer. Masternodes are the CoinJoin servers, so a pre-70241 masternode cannot host rebalance sessions after V24 activates. - **70242 `ASSET_UNLOCK_INV_VERSION`** (#7639): the `MSG_ASSET_UNLOCK` inventory type. Version 2 asset unlocks are announced by instance hash, so re-signed instances of one withdrawal, which share a txid, still propagate. Masternodes sign those re-issued withdrawals and InstantSend-lock them by withdrawal index. A masternode that only understands txid-based announcements does not reliably see every re-signed instance. ## What was done? - `src/version.h`: `MIN_MASTERNODE_PROTO_VERSION` 70240 → 70242 (= `PROTOCOL_VERSION`). - `test/functional/feature_llmq_simplepose.py`: its local copy `MIN_MASTERNODE_PROTO_VERSION = 70238` → 70242. ### Consumers of `MIN_MASTERNODE_PROTO_VERSION` A grep over `src/` and `test/` finds exactly one C++ consumer and one test mirror: 1. **`src/active/dkgsession.cpp` `ActiveDKGSession::VerifyConnectionAndMinProtoVersions()`**. This runs at the end of the DKG contribution phase on every participating masternode. For each other quorum member with a live MNAUTH-verified connection, it compares the peer's `nVersion` (the version the peer advertised; on non-mainnet networks this can be overridden with `-pushversion`) against the constant. If the peer's version is lower, the member is marked `badConnection`, and in the complaint phase this node votes it into `badMembers`. Once a member collects `dkgBadVotesThreshold` such votes (2 for the small test LLMQs, 7 for `llmq_test_dip0024`/`llmq_devnet*`, 40 for `llmq_50_60`, 48 for `llmq_60_75`, 300 for `llmq_400_*`), every honest member marks it `bad`. It is then left out of `validMembers` in the final commitment. When that commitment is mined, `HandleQuorumCommitment()` in `src/evo/specialtxman.cpp` applies `PoSePunish(CalcPenalty(66))` to the excluded member. If this repeats across DKG sessions, the masternode ends up PoSe-banned. Members that are not connected at all are not affected by this constant; they go through the separate `SPORK_21` all-connected rule. 2. **`test/functional/feature_llmq_simplepose.py`** mirrors the constant (details under testing). No other code paths use it: net_processing, `masternode/`, `llmq/` signing, sync, InstantSend, ChainLocks, and governance all have their own version constants or none. `MIN_PEER_PROTO_VERSION` (70221), which controls general peer disconnects, is unchanged. ### When does this take effect? It does **not** depend on `DEPLOYMENT_V24` or any other deployment, and not on the network either. The check is gated only on `SPORK_23_QUORUM_POSE` through `IsQuorumPoseEnabled()`: spork value 0 enables it for all LLMQ types, value 1 enables it for all types except `llmq_100_67`, `llmq_400_60` and `llmq_400_85`, and any other value disables it. So as soon as a masternode runs this code and SPORK_23 is on for the LLMQ type involved, it votes against DKG members that advertise less than 70242. It does not wait for V24 activation. Masternodes still running 23.1.x (70240) become bad DKG members, and eventually PoSe-banned, once enough upgraded quorum members reach `dkgBadVotesThreshold` in a session. How much this matters depends on how quickly operators upgrade on testnet and mainnet. This PR does not change the gating. ## How Has This Been Tested? `feature_llmq_simplepose.py` was reviewed along with the constant. The `force_old_mn_proto` case restarts one masternode with `-pushversion={MIN_MASTERNODE_PROTO_VERSION - 1}`. With SPORK_23 on, it expects that masternode to be PoSe-punished and banned (`test_banning`). With `--disable-spork23` it expects no punishment (`test_no_banning`). With the stale 70238 the test pushed 70237, which is below both the old (70240) and the new (70242) minimum. The case still passed, but it no longer checked the actual threshold, and it would keep passing if the bump were reverted. With 70242 the test pushes 70241, which is valid under the old minimum. The case now passes only because of this bump, so it directly covers the new value. No other test in `test/functional/` hardcodes a protocol version tied to this constant. `test_framework/p2p.py`'s `P2P_VERSION = 70242` is already current, and `p2p_sendtxrcncl.py`'s 70234 is unrelated. Tested on macOS arm64 (depends build, `--enable-debug --enable-werror --without-gui`). What ran: - `make`: success. - `src/test/test_dash --run_test=net_tests`: no errors. - `test/functional/test_runner.py feature_llmq_simplepose.py "feature_llmq_simplepose.py --disable-spork23" feature_llmq_dkgerrors.py feature_llmq_signing.py`: all passed (`feature_llmq_simplepose.py`, `feature_llmq_simplepose.py --disable-spork23`, `feature_llmq_dkgerrors.py`, `feature_llmq_signing.py`, `feature_llmq_signing.py --spork21`). No wider unit or functional suites were run. ## Breaking Changes Yes, for masternode operators. Suggested release-notes text: > **Minimum masternode protocol version raised to 70242.** v24 masternodes treat quorum members that advertise a protocol version below 70242 (any release before v24, including 23.1.x) as bad DKG participants whenever `SPORK_23_QUORUM_POSE` is active. This applies as soon as v24 masternodes are running and does not wait for the v24 hard fork. Masternodes that have not upgraded will be excluded from the quorums they are selected for and PoSe-punished for each missed DKG, leading to a PoSe ban. Operators should upgrade to v24 promptly. ## Checklist: - [x] I have performed a self-review of my own code - [ ] 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: 0fbf6d646aaf707e1e1fa6ee13cdf71cf592846ae12bc1c62959ab3c589efb96ddaccf2e08262b037550a182848a92b5bfa28d344061974943e24fe17870069c
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
3 participants
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.
Checklist