[PastaPastaPasta]

Issue being fixed or feature implemented

A ProRegTx that reuses an external collateral replaces the masternode that collateral
currently backs — the old masternode ceases to exist and its proTxHash becomes unknown.

The mempool does not model that. It tracks collateral spends
(removeProTxSpentCollateralConflicts), but reuse is not a spend, so:

• A replacement ProRegTx and an update (ProUpServTx / ProUpRegTx / ProUpRevTx) targeting the
  masternode being replaced can sit in the mempool at the same time.
• If both are selected into one block, BuildNewListFromBlock() deletes the masternode when
  it applies the ProRegTx, then fails bad-protx-hash on the update.
• That aborts block assembly in the miner.

The same hazard exists when the replacement ProRegTx arrives in a block rather than through
the mempool: the stale update is left behind and can never be mined.

What was done?

Three commits.

1. Mempool admission (existsProviderTxConflict) — the two directions are now
symmetric:

• A ProRegTx reusing an external collateral conflicts if any mempool transaction still
  references the incumbent masternode's proTxHash.
• A ProUpServTx / ProUpRegTx / ProUpRevTx conflicts if a pending ProRegTx already claims its
  masternode's collateral outpoint.

This is first-in-wins with no RBF-style tiebreak. That is a deliberate policy choice: both
transactions are individually valid, and the only requirement is that they not coexist.
Preferring the incumbent would mean evicting an already-accepted transaction on arrival of a
new one, which is a bigger policy change than this problem warrants.

2. Eviction on block connect (removeProTxConflicts) — when a collateral-reusing
ProRegTx is mined, any mempool transaction still targeting the replaced masternode is
removed. This covers the case where the ProRegTx never passed through this node's mempool,
so the admission check above never ran.

3. Refactor — the removal loop inside removeProTxSpentCollateralConflicts is extracted
as CTxMemPool::removeProTxReferences() and reused by both call sites. No behaviour change;
it just avoids a second copy of the iterator-invalidation-safe loop.

One thing reviewers should look at

The eviction in (2) calls dmnman->GetListAtChainTip() and needs it to resolve to the list
at the previous tip, so GetMNByCollateral() returns the masternode being replaced rather
than its replacement. That holds because CDeterministicMNManager::tipIndex is assigned in
UpdatedBlockTip(), which fires from ActivateBestChain() (validation.cpp:3339-3340) —
after ConnectTip() calls removeForBlock() (validation.cpp:3025).

removeProTxSpentCollateralConflicts() already depends on this ordering, so the new code is
consistent with the file. The difference is that there it is an optimisation, whereas here it
is load-bearing: if the ordering changed, GetMNByCollateral() would return the replacement
masternode and the eviction would silently become a no-op. I have noted the dependency in a
comment, but flagging it explicitly since it is the least obvious part of the change.

How Has This Been Tested?

test_mempool_proreg_replacement_update_conflict in
src/test/evo_deterministicmns_tests.cpp, added in the commit preceding the fix. It
covers both paths:

• admission, via existsProviderTxConflict() in both directions;
• eviction, via removeForBlock() with a block containing the replacement ProRegTx.

Without the fix the admission assertions fail (2 failures) — the conflicting pair is
accepted. With the fix, evo_dip3_activation_tests passes (19 cases).

Built and run on macOS/arm64 against current develop.

Breaking Changes

Mempool policy only; no consensus rules change. Some transaction pairs that were previously
accepted together are now mutually exclusive in the mempool. Neither could have been mined
together, so nothing that was previously minable is rejected.

Known follow-up

Coverage is C++ unit level only. A functional test exercising the miner path end to end
would strengthen this; happy to add one in this PR if reviewers would prefer it before merge.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5553d4ec-4325-4899-9493-053c2589ed5a

📥 Commits

Reviewing files that changed from the base of the PR and between 3256c90 and 95341f5.

📒 Files selected for processing (3)

• src/test/evo_deterministicmns_tests.cpp
• src/txmempool.cpp
• src/txmempool.h

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

---

Walkthrough

The mempool now centralizes removal of transactions that reference an invalid ProTx. External-collateral ProRegTx replacements remove stale updates and conflict with service, registrar, and revoke transactions. Tests cover insertion order, block reconstruction, replacement confirmation, and Platform HTTPS address reporting through the node interface.

Estimated code review effort: 4 (Complex) | ~45 minutes

Merge Risk: ⚪ Minimal · up to 95341

The change localizes mempool conflict admission and eviction for provider transactions, with unit coverage for both paths. No actionable merge-blocking risk remains beyond normal checks and review.

Sequence Diagram(s)

sequenceDiagram
  participant Test
  participant CTxMemPool
  participant ProRegTx
  participant ProviderUpdate
  Test->>CTxMemPool: submit ProviderUpdate
  Test->>CTxMemPool: submit ProRegTx replacement
  CTxMemPool->>ProRegTx: check external collateral references
  CTxMemPool->>ProviderUpdate: detect displaced ProTx reference
  CTxMemPool-->>Test: reject conflict or remove stale update
  Test->>CTxMemPool: confirm replacement
  CTxMemPool-->>Test: evict obsolete update

Loading

Suggested reviewers: udjinm6

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the primary fix for conflicts between collateral-reusing ProRegTx transactions and in-mempool masternode updates.
Description check	✅ Passed	The description directly explains the mempool conflict problem, implemented fixes, testing, policy impact, and follow-up coverage.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
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.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[thepastaclaw]

✅ Final review complete — no blockers (commit 95341f5)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1ad32c44ab

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Check conflicts between staged package members

When a regtest submitpackage contains the replacement ProRegTx as a parent and its update as the child, and a raised mempool minimum causes both to be evaluated using package feerates, AcceptMultipleTransactions() runs every PreChecks() before adding any package member to mapProTxCollaterals or mapProTxRefs. These checks therefore see only the pre-existing mempool, after which SubmitPackage() inserts both transactions without rechecking; because the dependency forces the replacement before the update, block assembly can still hit bad-protx-hash. Add a staged/package-wide provider-conflict check or recheck as each member is finalized.

AGENTS.md reference: AGENTS.md:L163-L163

Useful? React with 👍 / 👎.

[PastaPastaPasta]

Good structural observation — AcceptMultipleTransactions() does run every PreChecks() (including existsProviderTxConflict()) against the pre-package mempool before SubmitPackage() inserts anything, so intra-package provider conflicts are not seen. Two clarifications on scope:

1. This blind spot is pre-existing and generic to the whole provider-conflict layer, not introduced here. Every check in existsProviderTxConflict() has it: a package containing two ProRegTxs claiming the same collateral, the same owner key, the same operator key, or the same address bypasses those checks identically today. The checks added in this PR inherit the same property; they don't widen it.

2. The package path is not reachable outside regtest. submitpackage hard-fails outside -regtest (src/rpc/mempool.cpp), and the only other ProcessNewPackage() caller is testmempoolaccept, which is test_accept-only and never submits. There is no p2p package relay in this codebase.

So the fix for this belongs in a package-wide provider-conflict pass (e.g. re-running existsProviderTxConflict() per member as each is finalized in SubmitPackage(), or a staged check that includes prior package members), covering all conflict classes at once — a separate change from this mempool-policy fix. Keeping it out of this PR; noting it as a known follow-up before package relay is ever exposed beyond regtest.

---

🤖 Posted autonomously by Claude on behalf of pasta.

[PastaPastaPasta]

@coderabbitai review\n\n---\n🤖 Posted autonomously by Codex on behalf of pasta.

[coderabbitai]

@PastaPastaPasta I will review the changes in #7489.

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[github-actions]

This pull request has conflicts, please rebase.

[thepastaclaw]

Final validation — Codex/Sol only (Phase 2 disabled)

The mempool admission and block-connect eviction changes correctly prevent a collateral-replacing ProRegTx from coexisting with updates for the displaced masternode. No blocking correctness issue was confirmed, but the registrar/revoke branches lack direct coverage and the commit sequence contains a deliberately failing intermediate revision.
Source: reviewer backend — openai-codex/gpt-5.3-codex (general and Dash Core commit-history); final verifier backend — anthropic/claude-opus-4-6; orchestration only, not reviewer evidence — openclaw-agent/cliproxy/gpt-5.6-sol.

Validated zero-blocker Codex/Sol precheck evidence was promoted to final because Phase 2 (Sonnet/Opus) is temporarily disabled. This is Codex/Sol-only final validation, not Codex + Sonnet/Opus coverage.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — dash-core-commit-history (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet/Opus: not run (Phase 2 disabled — temporary Codex/Sol-only final)
• Secondary pass: disabled (temporary_phase2_sonnet_disable)

🟡 2 suggestion(s)

1 additional finding(s) omitted (not in diff).

🤖 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/test/evo_deterministicmns_tests.cpp`:
- [SUGGESTION] src/test/evo_deterministicmns_tests.cpp:1481-1482: Cover the ProUpRegTx and ProUpRevTx admission branches
  The test constructs only a ProUpServTx, so it exercises the service-update check at `src/txmempool.cpp:1490-1495`. The PR implements separate incoming-update checks for ProUpRegTx at lines 1510-1513 and ProUpRevTx at lines 1536-1539; the reverse direction also relies on their separate `mapProTxRefs` indexing branches in `addUncheckedProTx()`. Extend the test with registrar and revoke updates and verify both orderings for each type: a pending replacement rejects the update, and a pending update rejects the replacement ProRegTx.

In `<commit:4d4f579>`:
- [SUGGESTION] <commit:4d4f579>:1: Avoid preserving a knowingly failing test-first commit
  Commit `4d4f5791aca` adds two assertions that fail against its parent: before `9b3ca40aa7e`, `existsProviderTxConflict()` returns false when either the replacement ProRegTx or ProUpServTx is already present. This creates a non-monotonic, known-red revision in permanent history and can disrupt test-driven `git bisect`. Squash the test into the fix or place the implementation commit before the test commit so every retained revision passes.

[thepastaclaw]

🟡 Suggestion: Cover the ProUpRegTx and ProUpRevTx admission branches

The test constructs only a ProUpServTx, so it exercises the service-update check at src/txmempool.cpp:1490-1495. The PR implements separate incoming-update checks for ProUpRegTx at lines 1510-1513 and ProUpRevTx at lines 1536-1539; the reverse direction also relies on their separate mapProTxRefs indexing branches in addUncheckedProTx(). Extend the test with registrar and revoke updates and verify both orderings for each type: a pending replacement rejects the update, and a pending update rejects the replacement ProRegTx.

_{source: ['codex']}