Fix compilation for old Boost versions
What changed, and why it matters
This commit is a straightforward build-compatibility fix. It replaces two newer Boost library function calls (`contains`) with older, equivalent alternatives (`find == end` and `count`) so Bitcoin Core can compile against Boost versions older than 1.78.0. There is no change to program logic, behavior, or security.
No security action required. Treat as a normal build-system compatibility fix.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch reverts use of boost::multi_index::contains, introduced in Boost 1.78.0, to equivalent pre-1.78 constructs: m_to_add.find(...) == m_to_add.end() in CTxMemPool::ChangeSet::StageAddition and m_index.get<ByPeer>().count(...) in txrequest.cpp. Both expressions preserve the original boolean semantics. The change is purely a portability/build fix.
Changed components
src/txmempool.cppsrc/txrequest.cppInspect captured patch +2 / −2
diff --git a/src/txmempool.cpp b/src/txmempool.cpp
index e63bff2a..49961896 100644
--- a/src/txmempool.cpp
+++ b/src/txmempool.cpp
@@ -988,7 +988,7 @@ util::Result<std::pair<std::vector<FeeFrac>, std::vector<FeeFrac>>> CTxMemPool::
CTxMemPool::ChangeSet::TxHandle CTxMemPool::ChangeSet::StageAddition(const CTransactionRef& tx, const CAmount fee, int64_t time, unsigned int entry_height, uint64_t entry_sequence, bool spends_coinbase, int64_t sigops_cost, LockPoints lp)
{
LOCK(m_pool->cs);
- Assume(!m_to_add.contains(tx->GetHash()));
+ Assume(m_to_add.find(tx->GetHash()) == m_to_add.end());
Assume(!m_dependencies_processed);
// We need to process dependencies after adding a new transaction.
diff --git a/src/txrequest.cpp b/src/txrequest.cpp
index bb013b0f..4d7240be 100644
--- a/src/txrequest.cpp
+++ b/src/txrequest.cpp
@@ -580,7 +580,7 @@ public:
// Bail out if we already have a CANDIDATE_BEST announcement for this (txhash, peer) combination. The case
// where there is a non-CANDIDATE_BEST announcement already will be caught by the uniqueness property of the
// ByPeer index when we try to emplace the new object below.
- if (m_index.get<ByPeer>().contains(ByPeerView{peer, true, gtxid.ToUint256()})) return;
+ if (m_index.get<ByPeer>().count(ByPeerView{peer, true, gtxid.ToUint256()})) return;
// Try creating the announcement with CANDIDATE_DELAYED state (which will fail due to the uniqueness
// of the ByPeer index if a non-CANDIDATE_BEST announcement already exists with the same txhash and peer).
Why this scored 15/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.