Skip to content

Fix ProUpServTx platformNodeID mempool conflict comparing txid to ProTx hash #7381

Description

@thepastaclaw

Context

Found while cleaning up CodeRabbit follow-up commits from #7379. The backmerge PR should stay as a pure merge from master into develop, so this needs to be handled separately on develop if confirmed.

Problem

At #7379's merge-back commit (22a3321aab8d41e2b0be913fdb55345cec62e12d), CTxMemPool::mapProTxPlatformNodeIDs stores a single uint256 value for a platform node ID.

For ProRegTx, that value is the ProTx hash because the transaction hash is the provider hash.

For ProUpServTx, addUnchecked() stores the update-service transaction hash:

mapProTxPlatformNodeIDs.emplace(proTx.platformNodeID, tx_hash);

But existsProviderTxConflict() later compares that stored value against the owning masternode's proTxHash:

if (it != mapProTxPlatformNodeIDs.end() && it->second != opt_proTx->proTxHash) {
    return true;
}

For update-service transactions, the mempool txid and owner proTxHash are different identifiers. That means a second pending ProUpServTx for the same masternode can be rejected as protx-dup when it keeps the same platformNodeID, even though it belongs to the same provider.

The removal path still needs the mempool transaction hash:

uint256 conflictHash = mapProTxPlatformNodeIDs[platformNodeID];

So the map likely needs to track both the conflicting mempool txid and the owning ProTx hash, or use another structure that preserves both lookups.

Scope

Please fix this as a normal develop follow-up, not as part of #7379's release-branch merge-back.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions