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.
Context
Found while cleaning up CodeRabbit follow-up commits from #7379. The backmerge PR should stay as a pure merge from
masterintodevelop, so this needs to be handled separately ondevelopif confirmed.Problem
At #7379's merge-back commit (
22a3321aab8d41e2b0be913fdb55345cec62e12d),CTxMemPool::mapProTxPlatformNodeIDsstores a singleuint256value 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:But
existsProviderTxConflict()later compares that stored value against the owning masternode'sproTxHash:For update-service transactions, the mempool txid and owner
proTxHashare different identifiers. That means a second pendingProUpServTxfor the same masternode can be rejected asprotx-dupwhen it keeps the sameplatformNodeID, even though it belongs to the same provider.The removal path still needs the mempool transaction hash:
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
developfollow-up, not as part of #7379's release-branch merge-back.