Invoke TxGraph::DoWork() at appropriate times
What changed, and why it matters
This commit adds calls to a background graph-maintenance routine (TxGraph::DoWork) after three kinds of mempool changes: applying a batch of new transactions, handling a blockchain reorganization, and processing a newly found block. It also defines a constant telling the graph how much cleanup work to do each time. The change looks like a performance or consistency fix: without these calls, the in-memory transaction graph might not be updated promptly, possibly leading to stale data, incorrect fee estimates, or degraded mempool behavior. There is no direct evidence in the commit that this fixes an exploitable security vulnerability.
Treat as a routine correctness/performance fix. Review the TxGraph::DoWork implementation and callers to confirm that POST_CHANGE_WORK is sufficient to keep the graph consistent under expected load, and that no other mutation paths (e.g., eviction, trimToSize) need similar calls. No emergency response is indicated by the available evidence.
Security signals we found
Missing state-synchronization call after critical mempool mutations
Potential for stale or inconsistent mempool graph metadata
Could affect fee estimation, eviction, or package-relay decisions if graph remains out of date
No explicit security claim, CVE reference, or bug disclosure in commit or supplied references
Evidence from the diff
The patch inserts m_txgraph->DoWork(POST_CHANGE_WORK) into CTxMemPool::Apply, CTxMemPool::removeForReorg, and CTxMemPool::removeForBlock, and defines POST_CHANGE_WORK as 5 * ACCEPTABLE_ITERS (8,500 iterations). These are the three main mutation points of the mempool state. The TxGraph data structure is used for ancestor/descendant fee/size calculations and related mempool policies. The change ensures that graph maintenance is triggered after state changes rather than being deferred indefinitely. The commit message and diff do not describe a specific bug symptom, CVE, or security boundary being crossed.
Changed components
src/txmempool.cppsrc/txmempool.hCTxMemPool::ApplyCTxMemPool::removeForReorgCTxMemPool::removeForBlockTxGraphInspect captured patch +7 / −0
diff --git a/src/txmempool.cpp b/src/txmempool.cpp
index 597d4864..5197fb01 100644
--- a/src/txmempool.cpp
+++ b/src/txmempool.cpp
@@ -211,6 +211,7 @@ void CTxMemPool::Apply(ChangeSet* changeset)
addNewTransaction(it);
}
+ m_txgraph->DoWork(POST_CHANGE_WORK);
}
void CTxMemPool::addNewTransaction(CTxMemPool::txiter newit)
@@ -357,6 +358,7 @@ void CTxMemPool::removeForReorg(CChain& chain, std::function<bool(txiter)> check
for (indexed_transaction_set::const_iterator it = mapTx.begin(); it != mapTx.end(); it++) {
assert(TestLockPointValidity(chain, it->GetLockPoints()));
}
+ m_txgraph->DoWork(POST_CHANGE_WORK);
}
void CTxMemPool::removeConflicts(const CTransaction &tx)
@@ -401,6 +403,7 @@ void CTxMemPool::removeForBlock(const std::vector<CTransactionRef>& vtx, unsigne
}
lastRollingFeeUpdate = GetTime();
blockSinceLastRollingFeeBump = true;
+ m_txgraph->DoWork(POST_CHANGE_WORK);
}
void CTxMemPool::check(const CCoinsViewCache& active_coins_tip, int64_t spendheight) const
diff --git a/src/txmempool.h b/src/txmempool.h
index e2020b65..a3487c04 100644
--- a/src/txmempool.h
+++ b/src/txmempool.h
@@ -55,6 +55,10 @@ static const uint32_t MEMPOOL_HEIGHT = 0x7FFFFFFF;
* iterations. */
static constexpr uint64_t ACCEPTABLE_ITERS = 1'700;
+/** How much work we ask TxGraph to do after a mempool change occurs (either
+ * due to a changeset being applied, a new block being found, or a reorg). */
+static constexpr uint64_t POST_CHANGE_WORK = 5 * ACCEPTABLE_ITERS;
+
/**
* Test whether the LockPoints height and time are still valid on the current chain
*/
Why this scored 25/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.