Optimized handle_notify_new_transactions's duplicate tx check - Check sha256 digests instead of full blobs (much less memory used) - Replace `find->insert` sequence with a single `insert` - 2x fewer hashset accesses - Preallocate the required size for the hashset (no full-table rehashes)
What changed, and why it matters
This commit is a performance optimization in Monero's transaction-processing code. It changes how the node detects duplicate transactions sent by a peer: instead of comparing the entire transaction data (which uses lots of memory), it compares small SHA-256 fingerprints. It also streamlines how those fingerprints are stored. There is no direct evidence this fixes a security bug, but it removes a memory-pressure path and hardens duplicate detection against subtle blob differences.
Treat as a benign performance/hardening patch. No urgent action required. If auditing, verify that `tools::sha256sum` cannot produce collisions for distinct blobs and that the digest is computed over the exact blob bytes used downstream, so duplicate detection remains semantically equivalent.
Security signals we found
Memory-usage reduction in network-facing message handler (defensive hardening against resource exhaustion)
Duplicate-transaction detection moved from full-blob equality to SHA-256 digest equality
No explicit security bug or CVE referenced in commit message
No bounds-checking or input-validation changes visible
Evidence from the diff
In cryptonote_protocol_handler.inl, handle_notify_new_transactions previously used an unordered_set<blobdata> to detect duplicate transaction blobs in a peer notification, performing a find() then insert(). The patch switches to unordered_set<crypto::hash>, computes a SHA-256 digest of each blob, reserves the set size up front, and uses a single insert() whose result indicates duplication. This reduces memory usage and hash-set operations. The duplicate-detection semantics are preserved, but the comparison is now cryptographic-digest-based rather than raw blob equality.
Changed components
src/cryptonote_protocol/cryptonote_protocol_handler.inlP2P transaction notification handler (`handle_notify_new_transactions`)Duplicate transaction detection logicInspect captured patch +9 / −3
diff --git a/src/cryptonote_protocol/cryptonote_protocol_handler.inl b/src/cryptonote_protocol/cryptonote_protocol_handler.inl
index e4c30ad..d012b91 100644
--- a/src/cryptonote_protocol/cryptonote_protocol_handler.inl
+++ b/src/cryptonote_protocol/cryptonote_protocol_handler.inl
@@ -915,17 +915,23 @@ namespace cryptonote
return 1;
}
- std::unordered_set<blobdata> seen;
+ std::unordered_set<crypto::hash> seen;
+ seen.reserve(arg.txs.size());
+
for (const auto &blob: arg.txs)
{
MLOGIF_P2P_MESSAGE(cryptonote::transaction tx; crypto::hash hash; bool ret = cryptonote::parse_and_validate_tx_from_blob(blob, tx, hash);, ret, "Including transaction " << hash);
- if (seen.find(blob) != seen.end())
+
+ crypto::hash digest{};
+ if (!blob.empty())
+ tools::sha256sum(reinterpret_cast<const uint8_t*>(blob.data()), blob.size(), digest);
+
+ if (!seen.insert(digest).second)
{
LOG_PRINT_CCONTEXT_L1("Duplicate transaction in notification, dropping connection");
drop_connection(context, false, false);
return 1;
}
- seen.insert(blob);
}
/* If the txes were received over i2p/tor, the default is to "forward"
Why this scored 19/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.