Repository navigation
backport: bitcoin#26177 - #7806
DCG-Claude wants to merge 1 commit into
Conversation
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
|
This pull request has conflicts, please rebase. |
Potential PR merge conflictsThis is advisory only. It does not block CI, but it marks PRs that will likely need a rebase depending on merge order. If this PR merges firstThese open PRs will likely need a rebase:
|
|
✅ Final review complete — no blockers (commit d5fea03) · triage: normal |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
WalkthroughChain-parameter declarations and implementations move into the kernel layer. Devnet and regtest argument parsing now collects settings into option structures that the network factories use. Build lists and consumers are updated to use the kernel chain-parameter interface. Snapshot validation looks up assumeutxo data through the chain parameters stored in its options. Priority: ➖ Normal Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant CreateChainParams
participant ReadRegTestArgs
participant ArgsManager
participant CChainParams
CreateChainParams->>ReadRegTestArgs: Collect regtest options
ReadRegTestArgs->>ArgsManager: Read command-line settings
ArgsManager-->>ReadRegTestArgs: Return setting values
ReadRegTestArgs-->>CreateChainParams: Return RegTestOptions
CreateChainParams->>CChainParams: Construct regtest parameters from options
CChainParams-->>CreateChainParams: Return chain parameters
Merge Risk: ⚪ Minimal · up to This change moves chain parameters into the kernel layer and keeps network behavior the same. The earlier problem with repeated -vbparams overrides has been fixed, and no other concrete regressions were found. Adding regression tests for repeated overrides is still recommended, but it does not block the merge. Pre-merge checks |
  |
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 24.14% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 58 functions across 27 files. | Write docstrings for the functions missing them to satisfy the coverage threshold. |
✅ Passed checks (4 passed)
-
Check name Status Explanation Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Title check The title identifies the upstream pull request being backported. It is concise and directly related to the changeset, although it does not state the specific chain-parameter refactor. Description check The description clearly explains that this pull request backports bitcoin#26177 and moves CChainParams and network classes into kernel/chainparams.{h,cpp}.
- Fix all pre-merge checks with AI
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
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 @coderabbitai help to get the list of available commands.
8c6e8c4 to
f36ceda
Compare
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Final validation — Phase 1 + Phase 2
Verified both supplied findings against head f36ceda. Enabling production submitpackage exposes a confirmed Dash-specific provider-conflict gap that can prevent block-template creation; the header-hygiene nitpick is dropped as unchanged upstream style with no current compilation defect. Verification was static only: the supplied CI snapshot shows successful Linux, SQLite, no-wallet, fuzz and ARM builds plus lint, with other builds and test jobs still pending.
🔴 1 blocking
Review provenance
Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: backport-reviewer); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
normalbygpt-6.1-sol(effort low) — The large chain-parameter relocation and submitpackage RPC/topology changes warrant ordinary cross-cutting review, but the diff does not clearly change consensus rules, funds movement, cryptography, network deserialization, or storage migrations. - Phase 1 reviewers:
muse-spark-1.3-contributor— general (completed, effort xhigh); agentphase1-reviewer - Phase 1 model:
muse-spark-1.3-contributor— not quota-gated; passed overgemini-3.8-flash-high(antigravity below 15% reserve: weekly 15% left, 5h 100% left),glm-5.3-flash(not used above high effort; tier asks max) - Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— backport-reviewer (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— dash-core-commit-history (completed, effort high); agentphase2-reviewer
🤖 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 `src/rpc/mempool.cpp`:
- [BLOCKING] src/rpc/mempool.cpp:806-808: Validate intra-package ProTx conflicts before enabling production submission
The child-with-parents restriction permits two independently funded ProRegTx parents claiming the same operator key and a child spending both parents' change outputs. Give each parent a fee above minimum relay but below the current mempool minimum, and give the child enough fee to lift the package above that minimum. AcceptPackage then defers both parents to AcceptMultipleTransactions, which runs every PreChecks before inserting any transaction. Both provider-conflict checks inspect only the existing mempool, and CheckSpecialTx checks the chain-tip masternode list, so neither parent sees the sibling's claim. The package checks reject input double-spends and duplicate asset-unlock indexes, but not provider conflicts; SubmitPackage subsequently inserts both through Finalize/addUnchecked without rechecking them. The later BroadcastTransaction calls also skip admission checks for transactions already in the mempool.
BlockAssembler validates each special transaction against the tip rather than a cumulatively updated masternode list, so it can select this ancestor package. BuildNewListFromBlock then rejects the second registration with bad-protx-dup-key, causing CreateNewBlock to throw while the conflicting entries remain eligible. Removing the regtest-only guard exposes this failure on production networks. Validate provider conflicts across the package before batch insertion and add a regression covering conflicting low-fee ProRegTx parents with a fee-bumping child.
| if (!IsChildWithParentsTree(txns)) { | ||
| throw JSONRPCTransactionError(TransactionError::INVALID_PACKAGE, "package topology disallowed. not child-with-parents or parents depend on each other."); | ||
| } |
There was a problem hiding this comment.
✅ No longer applies at
e4d54cd7; see the replies below.
🔴 Blocking: Validate intra-package ProTx conflicts before enabling production submission
The child-with-parents restriction permits two independently funded ProRegTx parents claiming the same operator key and a child spending both parents' change outputs. Give each parent a fee above minimum relay but below the current mempool minimum, and give the child enough fee to lift the package above that minimum. AcceptPackage then defers both parents to AcceptMultipleTransactions, which runs every PreChecks before inserting any transaction. Both provider-conflict checks inspect only the existing mempool, and CheckSpecialTx checks the chain-tip masternode list, so neither parent sees the sibling's claim. The package checks reject input double-spends and duplicate asset-unlock indexes, but not provider conflicts; SubmitPackage subsequently inserts both through Finalize/addUnchecked without rechecking them. The later BroadcastTransaction calls also skip admission checks for transactions already in the mempool.
BlockAssembler validates each special transaction against the tip rather than a cumulatively updated masternode list, so it can select this ancestor package. BuildNewListFromBlock then rejects the second registration with bad-protx-dup-key, causing CreateNewBlock to throw while the conflicting entries remain eligible. Removing the regtest-only guard exposes this failure on production networks. Validate provider conflicts across the package before batch insertion and add a regression covering conflicting low-fee ProRegTx parents with a fee-bumping child.
source: gpt-6.1-sol (phase2-reviewer: general)
There was a problem hiding this comment.
Confirmed: AcceptMultipleTransactions only rejects input double-spends and duplicate asset-unlock indexes within a package. Provider conflicts are checked only against the existing mempool and tip MN list (existsProviderTxConflict, CheckSpecialTx), so lifting the regtest guard as bitcoin#27609 does exposes sibling ProRegTx conflicts on production networks. The fix is a new Dash-specific package-level provider-conflict check plus a regression test, not a backport adaptation, so bitcoin#27609 should wait until that Dash prerequisite lands. Dropping bitcoin#27609 from this branch; it is being rewritten without it.
🤖 backportsys, on behalf of the Dash backport pipeline.
There was a problem hiding this comment.
I agree that dropping bitcoin#27609 from this batch resolves the production-exposure concern: the preceding commit still has the IsMockableChain() guard in submitpackage. Keeping the package-level provider-conflict validation and regression in a separate Dash prerequisite makes sense. The removal is not present in the checked-out head yet, so this remains pending the rewritten branch.
The finding stands on this commit until that change is pushed; the push gets a full review.
There was a problem hiding this comment.
Resolved (re-reviewed at 9ab1778b): Dropping bitcoin#27609 addresses the production-enablement issue: the current submitpackage handler rejects non-mockable chains before decoding or admitting transactions, and only regtest is mockable. This resolves the finding for this PR without claiming that intra-package ProTx conflict validation has been implemented.
There was a problem hiding this comment.
No longer applies (re-reviewed at e4d54cd7): Your removal of bitcoin#27609 is reflected in the current range, which contains no submitpackage changes. I verified that the non-regtest rejection remains in the handler, so this production-exposure finding no longer applies to this PR.
thepastaclaw
added
the
pastaclaw:changes-requested
|
Same issue as the inline finding: removing the submitpackage regtest guard exposes Dash's missing intra-package ProTx conflict validation on production networks. That needs new Dash code first, so bitcoin#27609 should be dropped from this batch until it exists. Dropping bitcoin#27609 from this branch; it is being rewritten without it. 🤖 backportsys, on behalf of the Dash backport pipeline. |
f36ceda to
9ab1778
Compare
thepastaclaw
removed
the
pastaclaw:changes-requested
DCG-Claude
changed the title
|
Branch rewritten at
🤖 backportsys, on behalf of the Dash backport pipeline. |
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Re-review — Final validation — Phase 1 + Phase 2
Verified the supplied findings against head 9ab1778 and its base. One blocking Dash-specific regression remains: repeated -vbparams arguments discard previously supplied optional activation settings; the header-include nitpick is unchanged upstream code and is dropped under the backport review policy. The prior production submitpackage exposure is fixed by restoring the regtest-only guard; verification was static, and the supplied CI snapshot shows successful builds and lint checks with tests and several builds still pending.
🔴 1 blocking
Review provenance
Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: backport-reviewer); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
normalbygpt-6.1-sol(effort low) — The cross-cutting refactor moves CChainParams into src/kernel/chainparams.{h,cpp} and restructures argument-driven construction without clearly changing consensus rules or another qualifying critical surface. - Phase 1 reviewers:
muse-spark-1.3-contributor— general (completed, effort xhigh); agentphase1-reviewer - Phase 1 model:
muse-spark-1.3-contributor— not quota-gated; passed overgemini-3.8-flash-high(antigravity below 15% reserve: weekly 15% left, 5h 100% left),glm-5.3-flash(not used above high effort; tier asks max) - Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— backport-reviewer (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— dash-core-commit-history (completed, effort high); agentphase2-reviewer
🤖 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 `src/chainparams.cpp`:
- [BLOCKING] src/chainparams.cpp:89-92: Preserve optional Dash settings across repeated vbparams overrides
Replacing the entire deployment-map entry discards optional Dash settings supplied by an earlier -vbparams argument for the same deployment. Before this refactor, each argument immediately called UpdateVersionBitsParameters, whose optional fields left the current value unchanged when omitted or set to -1. The new parser initializes those fields to -1 and overwrites the previous entry; the kernel then applies only that final entry, leaving network defaults instead of the earlier overrides. For example, `-vbparams=v24:0:999999999999:0:10:8:6:5:0` followed by `-vbparams=v24:1:999999999999` previously retained the 10-block window, thresholds 8/6, and disabled EHF while changing the start time. At this head it instead uses the default 250-block window, thresholds 200/150, and enabled EHF. Merge optional fields per deployment, preserving earlier values whenever the later value is -1, while retaining last-argument behavior for start time, timeout, and minimum activation height. Add regression coverage for repeated overrides with both omitted and explicit -1 optional fields.
| for (int j=0; j < (int)Consensus::MAX_VERSION_BITS_DEPLOYMENTS; ++j) { | ||
| if (vDeploymentParams[0] == VersionBitsDeploymentInfo[j].name) { | ||
| UpdateVersionBitsParameters(Consensus::DeploymentPos(j), nStartTime, nTimeout, min_activation_height, nWindowSize, nThresholdStart, nThresholdMin, nFalloffCoeff, nUseEHF); | ||
| options.version_bits_parameters[Consensus::DeploymentPos(j)] = vbparams; | ||
| found = true; |
There was a problem hiding this comment.
✅ Resolved at
57982c01; see the replies below.
🔴 Blocking: Preserve optional Dash settings across repeated vbparams overrides
Replacing the entire deployment-map entry discards optional Dash settings supplied by an earlier -vbparams argument for the same deployment. Before this refactor, each argument immediately called UpdateVersionBitsParameters, whose optional fields left the current value unchanged when omitted or set to -1. The new parser initializes those fields to -1 and overwrites the previous entry; the kernel then applies only that final entry, leaving network defaults instead of the earlier overrides. For example, -vbparams=v24:0:999999999999:0:10:8:6:5:0 followed by -vbparams=v24:1:999999999999 previously retained the 10-block window, thresholds 8/6, and disabled EHF while changing the start time. At this head it instead uses the default 250-block window, thresholds 200/150, and enabled EHF. Merge optional fields per deployment, preserving earlier values whenever the later value is -1, while retaining last-argument behavior for start time, timeout, and minimum activation height. Add regression coverage for repeated overrides with both omitted and explicit -1 optional fields.
source: gpt-6.1-sol (phase2-reviewer: general)
There was a problem hiding this comment.
Same issue as the summary review: optional Dash -vbparams fields left at -1 now keep the value from an earlier -vbparams for the same deployment, which restores how UpdateVersionBitsParameters behaved before the refactor. (folded into the bitcoin#26177 commit)
🤖 backportsys, on behalf of the Dash backport pipeline.
There was a problem hiding this comment.
Resolved (re-reviewed at 57982c01): Verified your folded-in fix: all five optional Dash fields preserve the earlier entry when a later argument omits them or supplies -1, and kernel construction applies the merged values with the original sentinel semantics. The blocking behavior regression is fixed; the separate suggestion concerns missing regression coverage.
thepastaclaw
added
the
pastaclaw:changes-requested
|
This pull request has conflicts, please rebase. |
9ab1778 to
57982c0
Compare
|
Confirmed: this is a regression caused by the Dash adaptation, not by upstream. Upstream -vbparams has no optional fields, so last-wins is harmless there, but the old Dash code kept earlier window/threshold/falloff/useEHF values when a later argument passed -1 or left them out. ReadRegTestActivationArgs now carries those optional fields over from the existing map entry when the new value is -1, while start/timeout/min_activation_height still follow the last argument, as before; no new regression test was added. (folded into the 🤖 backportsys, on behalf of the Dash backport pipeline. |
thepastaclaw
removed
the
pastaclaw:changes-requested
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Re-review — Final validation — Phase 1 + Phase 2
Static verification of the complete diff at 57982c0 found no remaining blocking defects, and both prior findings are addressed. One in-scope suggestion remains: regression coverage for the new repeated -vbparams merge logic. No local builds or tests were run; current CI shows macOS and fuzz builds passing, other source builds and lint pending, and check_merge failing on a src/chainparams.cpp conflict with develop.
🟡 1 suggestion(s)
Review provenance
Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: backport-reviewer); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: backport-reviewer); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
normalbygpt-6.1-sol(effort low) — The large cross-cutting refactor relocates chain parameters and separates argument parsing from their construction in src/chainparams.cpp and src/kernel/chainparams.cpp, without clearly changing consensus rules or another qualifying critical surface. - Phase 1 reviewers:
muse-spark-1.3-contributor— general (completed, effort xhigh); agentphase1-reviewer - Phase 1 model:
muse-spark-1.3-contributor— not quota-gated; passed overgemini-3.8-flash-high(antigravity below 15% reserve: weekly 15% left, 5h 100% left),glm-5.3-flash(not used above high effort; tier asks max) - Fresh final gate: an independent Phase-2 review ran after iterative findings were reconciled
- Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— backport-reviewer (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— dash-core-commit-history (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— backport-reviewer (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— dash-core-commit-history (completed, effort high); agentphase2-reviewer
🤖 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 `src/chainparams.cpp`:
- [SUGGESTION] src/chainparams.cpp:93-99: Add regression coverage for repeated Dash vbparams overrides
The new merge logic correctly preserves earlier optional Dash values, but the behavior that regressed during this extraction has no regression coverage. The override cases in src/test/versionbits_tests.cpp each supply a single three- or four-field argument; other existing tests do not exercise repeated overrides for the same deployment. Extend the existing tests through CreateChainParams with repeated arguments whose later override omits the optional fields or explicitly supplies -1, checking the resulting window, thresholds, falloff coefficient, and useEHF. Also cover later explicit values replacing earlier ones and an override without earlier optional values retaining network defaults. Verify that start time, timeout, and minimum activation height remain last-argument-wins. These cases would protect the Dash-specific adaptation through its public construction API rather than private parser state.
| auto& entry = options.version_bits_parameters[Consensus::DeploymentPos(j)]; | ||
| if (vbparams.window_size == -1) vbparams.window_size = entry.window_size; | ||
| if (vbparams.threshold_start == -1) vbparams.threshold_start = entry.threshold_start; | ||
| if (vbparams.threshold_min == -1) vbparams.threshold_min = entry.threshold_min; | ||
| if (vbparams.falloff_coeff == -1) vbparams.falloff_coeff = entry.falloff_coeff; | ||
| if (vbparams.use_ehf == -1) vbparams.use_ehf = entry.use_ehf; | ||
| entry = vbparams; |
There was a problem hiding this comment.
🟡 Suggestion: Add regression coverage for repeated Dash vbparams overrides
The new merge logic correctly preserves earlier optional Dash values, but the behavior that regressed during this extraction has no regression coverage. The override cases in src/test/versionbits_tests.cpp each supply a single three- or four-field argument; other existing tests do not exercise repeated overrides for the same deployment. Extend the existing tests through CreateChainParams with repeated arguments whose later override omits the optional fields or explicitly supplies -1, checking the resulting window, thresholds, falloff coefficient, and useEHF. Also cover later explicit values replacing earlier ones and an override without earlier optional values retaining network defaults. Verify that start time, timeout, and minimum activation height remain last-argument-wins. These cases would protect the Dash-specific adaptation through its public construction API rather than private parser state.
source: gpt-6.1-sol (phase2-reviewer: general)
There was a problem hiding this comment.
The finding agrees the backported merge logic is correct: optional Dash fields left at -1 keep the value from an earlier -vbparams for the same deployment, as UpdateVersionBitsParameters() did before. It asks for new tests that upstream bitcoin#26177 doesn't ship and that aren't fixing anything the backport got wrong, so they belong in a separate Dash PR, not this commit.
🤖 backportsys, on behalf of the Dash backport pipeline.
There was a problem hiding this comment.
Still applies (re-reviewed at e4d54cd7): You are right that upstream bitcoin#26177 supplies no such test, so this is not a backport-completeness requirement. I retain it only as a non-blocking suggestion because a repeated-argument test would specifically exercise the map-composition behavior introduced by this extraction, which none of the existing single-override cases observes.
thepastaclaw
added
the
pastaclaw:commented
57982c0 to
e4d54cd
Compare
thepastaclaw
removed
the
pastaclaw:commented
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Re-review — Final validation — Phase 1 + Phase 2
Reviewed the complete diff at e4d54cd and compared the applicable transformations with Bitcoin Core bitcoin#26177. Dash's network parameters and extensions are preserved, and both prior blocking issues are addressed; one non-blocking regression-coverage suggestion remains. Validation was static only: the supplied CI snapshot has the main validation job and several supporting checks queued, so passing build/test validation at this head remains unconfirmed.
🟡 1 suggestion(s)
1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.
Review provenance
Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: backport-reviewer); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: backport-reviewer); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
normalbygpt-6.1-sol(effort low) — The large, cross-cutting refactor moves chain parameters into src/kernel/chainparams.{h,cpp} and decouples argument parsing through options structs, but does not clearly change consensus rules or another qualifying critical surface. - Phase 1 reviewers:
muse-spark-1.3-contributor— general (completed, effort xhigh); agentphase1-reviewer - Phase 1 model:
muse-spark-1.3-contributor— not quota-gated; passed overgemini-3.8-flash-high(antigravity below 15% reserve: weekly 15% left, 5h 100% left),glm-5.3-flash(not used above high effort; tier asks max) - Fresh final gate: an independent Phase-2 review ran after iterative findings were reconciled
- Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— backport-reviewer (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— dash-core-commit-history (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— backport-reviewer (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— dash-core-commit-history (completed, effort high); agentphase2-reviewer
🤖 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 `src/chainparams.cpp`:
- [SUGGESTION] src/chainparams.cpp:93-99: Add regression coverage for repeated Dash vbparams overrides
(existing thread: https://github.com/dashpay/dash/pull/7806#discussion_r4201301892)
The merge correctly preserves earlier optional Dash settings when a later override omits them or supplies -1. However, this extraction changes their composition from immediate updates to an accumulated deployment map, and the existing tests do not exercise repeated overrides for the same deployment: src/test/versionbits_tests.cpp supplies only single three- or four-field overrides, while the Dash-specific cases elsewhere supply one override per deployment. Add a focused table-driven test through CreateChainParams covering later omitted fields, explicit -1 retaining earlier values, explicit values replacing earlier ones, and network defaults remaining intact when no earlier optional value exists. Check the window, both thresholds, falloff coefficient, and useEHF, alongside last-argument behavior for start time, timeout, and minimum activation height. This protects the Dash adaptation introduced here; it is not an omitted upstream test or a remaining correctness blocker.
e4d54cd to
d45005f
Compare
…nctionality to kernel b3e78dc refactor: Don't use global chainparams in chainstatemanager method (TheCharlatan) 382b692 Split non/kernel chainparams (Carl Dong) edabbc7 Add factory functions for Main/Test/Sig/Reg chainparams (Carl Dong) d938098 Remove UpdateVersionBitsParameters (Carl Dong) 84b8578 Decouple RegTestChainParams from ArgsManager (Carl Dong) 76cd4e7 Decouple SigNetChainParams from ArgsManager (Carl Dong) Pull request description: This pull request is part of the `libbitcoinkernel` project bitcoin#24303 https://github.com/bitcoin/bitcoin/projects/18 and more specifically its "Step 2: Decouple most non-consensus code from libbitcoinkernel". dongcarl is the original author of this patchset, these commits were taken from https://github.com/dongcarl/bitcoin/tree/2022-03-libbitcoinkernel-chainparams-args-only. #### Context The bitcoin kernel library currently relies on code containing user configurations through the `ArgsManager`. This is not optimal, since as a stand-alone library it should not rely on bitcoind's argument parsing logic. Instead, its interfaces should accept control and options structs that control the kernel library's desired configuration. Similar work towards decoupling the `ArgsManager` from the kernel has been done in bitcoin#25290, bitcoin#25487, bitcoin#25527 and bitcoin#25862. #### Changes By moving the `CChainParams` class definition into the kernel and giving it new factory functions `CChainParams::{RegTest,SigNet,Main,TestNet}`it can be constructed without an `ArgsManager` reference, unlike the current factory function `CreateChainParams`. The first few commits remove uses of `ArgsManager` within `CChainParams`. Then the `CChainParams` definition is moved to a new file in the `kernel/` subdirectory. ACKs for top commit: MarcoFalke: re-ACK b3e78dc 🛁 ryanofsky: Code review ACK b3e78dc. Only changes since last review were recent review suggestions. ajtowns: ACK b3e78dc Tree-SHA512: 3835aca1d3e3c75cc3303dd584bab3a77e58f6c678724a5e359fe4b0e17e0763a00931ee6191f516b9fde50496f59cc691f0709c0254206db3863bbf7ab2cacd Dash adaptations: - src/kernel/chainparams.{h,cpp}: moves Dash's CChainParams and network classes (all DIP, LLMQ, masternode and spork parameters), not Bitcoin's - src/kernel/chainparams.{h,cpp}: adds CChainParams::DevNet(DevNetOptions) next to Main()/TestNet()/RegTest() for Dash's fourth network - src/kernel/chainparams.h: VersionBitsParameters, RegTestOptions and DevNetOptions carry Dash's extra -vbparams fields and regtest/devnet overrides - src/kernel/chainparams.cpp: LLMQ overrides arrive as quorum names and are resolved in the kernel constructors, which own the per-chain LLMQ list - src/kernel/chainparams.cpp: the devnet name comes from DevNetOptions::name instead of gArgs.GetDevNetName(), keeping the kernel gArgs-free - src/kernel/chainparams.cpp: the moved classes keep develop's current values (EvoSnapshotHash, V24 bit 13, EVO_SHARES; no fRequireStandard after bitcoin#28354) - src/deploymentinfo.cpp: GetBuriedDeployment() maps the 12 names -testactivationheight already accepted (bip147 ... mn_rr) instead of upstream's segwit - src/chainparams.cpp: Dash's arg readers stay split into ReadRegTest*/ReadDevNet* helpers, called from ReadRegTestArgs()/ReadDevNetArgs() - src/chainparams.cpp: -minimumdifficultyblocks/-highsubsidyblocks/-highsubsidyfactor are read as separate optionals, so they log three lines instead of one - src/validation.h: upstream's <fs.h> is not added; Dash uses util/fs.h - src/active/dkgsession.cpp, src/chainlock/signing.cpp, src/instantsend/net_instantsend.cpp and Dash tests: include <chainparams.h>, which validation.h no longer provides Not applicable to Dash (intentionally omitted): - src/kernel/chainparams.cpp: CSigNetParams and CChainParams::SigNet(); Dash has no signet - src/kernel/chainparams.h: SigNetOptions and the SigNet() declaration; Dash has no signet - src/chainparams.cpp: ReadSigNetArgs() and the SIGNET branch of CreateChainParams(); Dash has no signet - src/kernel/chainparams.cpp: segwit/taproot fields, script_flag_exceptions and bech32_hrp of Bitcoin's chain classes; Dash's classes have none - src/deploymentinfo.cpp: the "segwit" -> DEPLOYMENT_SEGWIT mapping; Dash has no segwit deployment
d45005f to
d5fea03
Compare
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Re-review — Final validation — Phase 1 + Phase 2
Verified the complete diff at d5fea03 and found no remaining in-scope correctness or backport-completeness issues. The repeated-vbparams repair preserves the original Dash semantics, production submitpackage exposure is absent, and additional repeated-override regression coverage remains intentionally deferred. This was static verification only: the supplied head-specific CI snapshot reports successful platform builds, lint, and nowallet tests, while standard Linux and SQLite tests and sanitizer and multiprocess builds remain pending.
🔴 0 blocking | 🟡 0 suggestion(s) | 💬 0 nitpick(s)
Review provenance
Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: backport-reviewer); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: backport-reviewer); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
normalbygpt-6.1-sol(effort low) — This is a large, cross-cutting refactor moving chain-parameter construction into the kernel and adapting configuration and callers, rather than changing consensus rules or another qualifying critical surface. - Phase 1 reviewers:
muse-spark-1.3-contributor— general (completed, effort xhigh); agentphase1-reviewer - Phase 1 model:
muse-spark-1.3-contributor— not quota-gated; passed overgemini-3.8-flash-high(antigravity below 15% reserve: weekly 14% left, 5h 100% left),glm-5.3-flash(not used above high effort; tier asks max) - Fresh final gate: an independent Phase-2 review ran after iterative findings were reconciled
- Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— backport-reviewer (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— dash-core-commit-history (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— backport-reviewer (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— dash-core-commit-history (completed, effort high); agentphase2-reviewer
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify the current code and confirm that no unresolved issues remain.
No unresolved findings remain from the prior review on this head.
2 participants
Issue being fixed or feature implemented
Backports 1 Bitcoin Core v0.26 pull request(s) that the Dash queue selected, including any discovered prerequisites: bitcoin#26177.
What was done?
d5fea03a6cEach commit keeps the upstream subject (
partial Merge …only where a hunk is deferred to a prerequisite still to be backported, named in the commit body; a hunk Dash intentionally never wants is recorded in the commit body or the reviewer's note above and does not make the backport partial). Conflicts were resolved commit by commit; commits that needed no resolution were cherry-picked unchanged.How Has This Been Tested?
Recorded per commit, at that commit's own sha, not once for the branch:
d5fea03a6c— no passing CI record at this headGates that did not come back clean — please weigh these:
mech: warn — 878 invented line(s); 194 Dash-feature line(s) removed; 6 partial/prereq/low-risk finding(s)Breaking Changes
None beyond the upstream changes themselves.
Checklist:
Left for the reviewer; backportsys does not tick boxes on its own behalf.
Maintainer controls
Tick a box and backportsys acts on it within a few minutes, then clears the box. For anything else — a hunk to drop, a resolution to redo, a question — just leave a review comment; nothing here needs a box.
develop