rpc: add optimal result to getmempoolinfo
What changed, and why it matters
This commit simply adds a new read-only field called 'optimal' to the getmempoolinfo RPC output. It exposes whether the mempool is currently in a known-optimal transaction ordering. There is no change to transaction processing, consensus rules, or network behavior—only an additional diagnostic value returned by an RPC call.
No security action required. This is a benign RPC diagnostic enhancement.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch adds one key to the MempoolInfoToJSON() helper and its corresponding RPCHelpMan documentation in src/rpc/mempool.cpp. The value is obtained from pool.m_txgraph->DoWork(0), which the inline comment describes as a quick check for known optimality. A functional test in mempool_cluster.py verifies the key exists and is true in trivial scenarios. No logic affecting mempool acceptance, eviction, mining, or P2P is modified.
Changed components
src/rpc/mempool.cpptest/functional/mempool_cluster.pyInspect captured patch +8 / −0
diff --git a/src/rpc/mempool.cpp b/src/rpc/mempool.cpp
index 66ce1c61..d9e135b6 100644
--- a/src/rpc/mempool.cpp
+++ b/src/rpc/mempool.cpp
@@ -874,6 +874,7 @@ UniValue MempoolInfoToJSON(const CTxMemPool& pool)
ret.pushKV("maxdatacarriersize", pool.m_opts.max_datacarrier_bytes.value_or(0));
ret.pushKV("limitclustercount", pool.m_opts.limits.cluster_count);
ret.pushKV("limitclustersize", pool.m_opts.limits.cluster_size_vbytes);
+ ret.pushKV("optimal", pool.m_txgraph->DoWork(0)); // 0 work is a quick check for known optimality
return ret;
}
@@ -900,6 +901,7 @@ static RPCHelpMan getmempoolinfo()
{RPCResult::Type::NUM, "maxdatacarriersize", "Maximum number of bytes that can be used by OP_RETURN outputs in the mempool"},
{RPCResult::Type::NUM, "limitclustercount", "Maximum number of transactions that can be in a cluster (configured by -limitclustercount)"},
{RPCResult::Type::NUM, "limitclustersize", "Maximum size of a cluster in virtual bytes (configured by -limitclustersize)"},
+ {RPCResult::Type::BOOL, "optimal", "If the mempool is in a known-optimal transaction ordering"},
}},
RPCExamples{
HelpExampleCli("getmempoolinfo", "")
diff --git a/test/functional/mempool_cluster.py b/test/functional/mempool_cluster.py
index 921f7441..6fe38771 100755
--- a/test/functional/mempool_cluster.py
+++ b/test/functional/mempool_cluster.py
@@ -306,6 +306,9 @@ class MempoolClusterTest(BitcoinTestFramework):
assert_equal(node.getrawmempool(), [])
+ # Key should exist and be trivially optimal
+ assert node.getmempoolinfo()["optimal"]
+
# Not in-mempool
not_mempool_tx = self.wallet.create_self_transfer()
assert_raises_rpc_error(-5, "Transaction not in mempool", node.getmempoolcluster, not_mempool_tx["txid"])
@@ -367,6 +370,9 @@ class MempoolClusterTest(BitcoinTestFramework):
chunkfee = first_chunk_tx["fee"] + second_chunk_tx["fee"] + third_chunk_tx["fee"]
assert_equal(first_chunk_info, {'clusterweight': first_chunkweight + second_chunkweight + third_chunkweight, 'txcount': 3, 'chunks': [{'chunkfee': first_chunk_tx["fee"], 'chunkweight': first_chunkweight, 'txs': [first_chunk_tx["txid"]]}, {'chunkfee': second_chunk_tx["fee"], 'chunkweight': second_chunkweight, 'txs': [second_chunk_tx["txid"]]}, {'chunkfee': third_chunk_tx["fee"], 'chunkweight': third_chunkweight, 'txs': [third_chunk_tx["txid"]]}]})
+ # We expect known optimality directly after txn submission
+ assert node.getmempoolinfo()["optimal"]
+
# If we prioritise the last transaction it can join the second transaction's chunk.
node.prioritisetransaction(third_chunk_tx["txid"], 0, int(third_chunk_tx["fee"]*COIN) + 1)
first_chunk_info = node.getmempoolcluster(first_chunk_tx["txid"])
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.