<p>There is no RPC that can provide information about evicted/expired/conflicted mempool transactions.</p>
<p>The reason these mechanisms exists is because the mempool is limited in size (configurable how much). When it grows too big, some things have to be removed from it. No information is kept about these removed transactions, because that too would need memory.</p>
<p>What you can do is occasionally querying the <code>getrawmempool</code> RPC, which lists all <em>current</em> transactions, to see which transactions stay in there how long. You can also subscribe to the ZMQ event feeds to learn about new transactions coming in, and blocks coming. Transactions that get removed from the mempool as a result of these are respectively due to replacement (for transactions), eviction (for transactions, when mempool is full), inclusion (for blocks, if in the block), or conflicting (for blocks, if not in the block).</p>

CC BY-SA 4.0
2023-11-15T12:07:59.437Z
2023-11-15T12:07:59.437Z
Pieter Wuille
<p>I am working with Bitcoin Core version 25.0 and am facing a question about handling mempool transactions evicted for non-block inclusion reasons. My query pertains to any transaction that has existed in my node's mempool at some point, not just those constructed by me.</p>
<h3>Context:</h3>
<p>In instances where a transaction is evicted from the mempool for reasons other than block inclusion, I am interested in understanding the duration for which it remains accessible for querying through an RPC command.</p>
<h3>Specific Questions:</h3>
<p><strong>Duration of Accessibility:</strong> How long does a transaction, evicted for non-block inclusion reasons, remain queryable in Bitcoin Core version &gt;=25.0?</p>
<p><strong>RPC Methods:</strong> Is there a method or RPC command to look up details of these non-block inclusion evicted mempool transactions by their transaction ID?</p>
<h3>What I've Tried:</h3>
<p>I have used the <code>getrawtransaction</code> command with <code>-txindex</code> enabled. While it successfully retrieves transactions in the mempool or any block, it seems to fail for transactions evicted for non-block inclusion reasons, resulting in an error.</p>
<p><em><strong>500 Internal Server Error (Code: -5, Message: No such mempool or blockchain transaction. Use gettransaction for wallet transactions).</strong></em></p>

<transactions><unconfirmed-transactions><mempool>
Querying Non-Block Inclusion Evicted Mempool Transactions in Bitcoin Core >25.0
Jeff Trimmer
# Querying Non-Block Inclusion Evicted Mempool Transactions in Bitcoin Core >25.0

(Asked by: username_0 on 2023-11-15)

I am working with Bitcoin Core version 25.0 and am facing a question about handling mempool transactions evicted for non-block inclusion reasons. My query pertains to any transaction that has existed in my node's mempool at some point, not just those constructed by me.

### Context:

In instances where a transaction is evicted from the mempool for reasons other than block inclusion, I am interested in understanding the duration for which it remains accessible for querying through an RPC command.

### Specific Questions:

**Duration of Accessibility:** How long does a transaction, evicted for non-block inclusion reasons, remain queryable in Bitcoin Core version >=25.0?

**RPC Methods:** Is there a method or RPC command to look up details of these non-block inclusion evicted mempool transactions by their transaction ID?

### What I've Tried:

I have used the `getrawtransaction` command with `-txindex` enabled. While it successfully retrieves transactions in the mempool or any block, it seems to fail for transactions evicted for non-block inclusion reasons, resulting in an error.

***500 Internal Server Error (Code: -5, Message: No such mempool or blockchain transaction. Use gettransaction for wallet transactions).***

**Tags:** transactions, unconfirmed-transactions, mempool


---

## 1 answers

### Answer by username_1 on 2023-11-15. Score: 4 | Accepted answer

There is no RPC that can provide information about evicted/expired/conflicted mempool transactions.

The reason these mechanisms exists is because the mempool is limited in size (configurable how much). When it grows too big, some things have to be removed from it. No information is kept about these removed transactions, because that too would need memory.

What you can do is occasionally querying the `getrawmempool` RPC, which lists all *current* transactions, to see which transactions stay in there how long. You can also subscribe to the ZMQ event feeds to learn about new transactions coming in, and blocks coming. Transactions that get removed from the mempool as a result of these are respectively due to replacement (for transactions), eviction (for transactions, when mempool is full), inclusion (for blocks, if in the block), or conflicting (for blocks, if not in the block).


---

