tx pool: only increment m_txpool_weight for newly added pool txs
What the developer wrote
Authored by j-berman
tx pool: only increment m_txpool_weight for newly added pool txs
Otherwise we can end up double counting txs towards the weight,
which can over-state the pool weight. E.g. relay tx to node in
stem phase, add its weight to pool weight, then receive tx
from another node, then bump the pool weight again. That double
counts the tx towards the pool weight.
If the weight exceeds the max, the node will "prune" txs from the
pool. Thus, over-counting is probably a cause of, but perhaps
not the only cause of:
https://github.com/seraphis-migration/monero/issues/148
What changed, and why it matters
This fix corrects a bookkeeping bug in Monero's transaction memory pool. The pool tracks its total weight (size) and prunes transactions when it thinks it is too full. Because the same transaction could be counted twice—once when relayed privately and again when received from another peer—the pool could believe it was over its weight limit and remove transactions prematurely. This could make the node behave differently from honest nodes, potentially affecting transaction relay and network consistency, but it does not directly steal funds or break cryptography.
Apply the patch. Monitor whether the linked issue (seraphis-migration/monero#148) is fully resolved, as the commit notes this may be one cause among several. Consider adding an invariant check that m_txpool_weight equals the sum of stored transaction weights.
Security signals we found
Denial-of-service-like symptom: premature eviction of valid mempool transactions
State inconsistency between local pool weight and actual stored transactions
P2P/network-layer interaction bug (stem relay + broadcast)
No cryptographic or consensus flaw identified in the diff
Evidence from the diff
In tx_pool.cpp, m_txpool_weight was incremented unconditionally at the end of add_tx(), even when the transaction was already present in the pool (tvc.m_added_to_pool false). This caused double-counting of transaction weights when a tx entered the pool via one path (e.g., stem-phase relay) and was later received from a peer. The patch moves the weight increment behind the tvc.m_added_to_pool guard. Over-counting could trigger premature pruning when the pool weight exceeded its configured maximum.
Changed components
src/cryptonote_core/tx_pool.cppMonero transaction memory pool weight accountingTransaction pruning/relay logicInspect captured patch +2 / −1
diff --git a/src/cryptonote_core/tx_pool.cpp b/src/cryptonote_core/tx_pool.cpp
index c63465e..5039ab9 100644
--- a/src/cryptonote_core/tx_pool.cpp
+++ b/src/cryptonote_core/tx_pool.cpp
@@ -343,7 +343,8 @@ namespace cryptonote
}
tvc.m_verifivation_failed = false;
- m_txpool_weight += tx_weight;
+ if (tvc.m_added_to_pool)
+ m_txpool_weight += tx_weight;
++m_cookie;
Why this scored 53/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.