<p>There are two methods to do this: ZMQ and Tracepoints.</p>
<p>The <code>zmqpubsequence</code> can be used to notifications for all mempool events. See the <a href="https://github.com/bitcoin/bitcoin/pull/19572" rel="nofollow noreferrer">PR</a> and <a href="https://github.com/bitcoin/bitcoin/blob/master/test/functional/interface_zmq.py#L292" rel="nofollow noreferrer">test</a> for more information. It was designed specifically for the mempool mirroring use case.</p>
<p>The other method is tracepoints, but this requires applying a currently <a href="https://github.com/bitcoin/bitcoin/pull/24935" rel="nofollow noreferrer">draft PR</a>. Tracepoints work similarly to ZMQ in that your program will use a tracepoints interface and wait for notifications.</p>

CC BY-SA 4.0
2022-07-29T19:35:06.190Z
@1440000bytes Good point, forgot that `zmqpubsequence` was added. I've updated the answer.
Ava Chow
CC BY-SA 4.0
2023-02-16T11:46:44.697Z
I you want a project example which keeps a continuous updated copy of a mempool you can check https://github.com/mempoolexplorer/mempoolexplorer
dev7ba
CC BY-SA 4.0
2022-07-28T21:58:37.890Z
2022-07-29T19:34:44.297Z
2022-07-29T19:34:44.297Z
Ava Chow
<p>Let's say I want to build a database of transactions that is continuously being updated from a locally running Bitcoin Core node using JSON-RPC and ZeroMQ. My concern is how to make it robust against chain reorganizations and other events where transactions might get dropped.</p>
<p>If I restrict myself only to confirmed transactions, it seems simple enough to just listen for new blocks, and in the event of a reorganization, rollback all transactions confirmed at a specific height and reapply the new chaintip.</p>
<p>However, it gets more complicated if I also want to include unconfirmed transactions. Then for every new transaction (whether in the mempool or in a block) I need to check if it conflicts with one or more unconfirmed transactions and remove those. Bitcoin Core already does this, but other than publishing the new transaction in a <code>rawtx</code> ZeroMQ event it gives no indication that an unconfirmed transaction was dropped.</p>
<p>So, is there a simple way to maintain a mirror of Bitcoin Core's mempool?</p>
<p>Some ideas:</p>
<ul>
<li>Call the <code>getrawmempool</code> RPC every 30 seconds or so to get the current state of the mempool. This has the advantage of being very simple, but it's inefficient and it means the mirror will lag behind.</li>
<li>Maintain an index of all outputs that are spent by transactions currently in the mempool, and check every new transaction against it. However, I'm not sure this covers every case where a transaction needs to be dropped, and it certainly doesn't cover transactions dropped due to <code>-maxmempool</code> and <code>-mempoolexpiry</code>.</li>
</ul>

<bitcoin-core><json-rpc><development><mempool><zeromq>
How do I maintain a continuously updated copy of a local mempool?
Vojtěch Strnad
# How do I maintain a continuously updated copy of a local mempool?

(Asked by: username_0 on 2022-07-26)

Let's say I want to build a database of transactions that is continuously being updated from a locally running Bitcoin Core node using JSON-RPC and ZeroMQ. My concern is how to make it robust against chain reorganizations and other events where transactions might get dropped.

If I restrict myself only to confirmed transactions, it seems simple enough to just listen for new blocks, and in the event of a reorganization, rollback all transactions confirmed at a specific height and reapply the new chaintip.

However, it gets more complicated if I also want to include unconfirmed transactions. Then for every new transaction (whether in the mempool or in a block) I need to check if it conflicts with one or more unconfirmed transactions and remove those. Bitcoin Core already does this, but other than publishing the new transaction in a `rawtx` ZeroMQ event it gives no indication that an unconfirmed transaction was dropped.

So, is there a simple way to maintain a mirror of Bitcoin Core's mempool?

Some ideas:

* Call the `getrawmempool` RPC every 30 seconds or so to get the current state of the mempool. This has the advantage of being very simple, but it's inefficient and it means the mirror will lag behind.
* Maintain an index of all outputs that are spent by transactions currently in the mempool, and check every new transaction against it. However, I'm not sure this covers every case where a transaction needs to be dropped, and it certainly doesn't cover transactions dropped due to `-maxmempool` and `-mempoolexpiry`.

**Tags:** bitcoin-core, json-rpc, development, mempool, zeromq


---

## 1 answers

### Answer by username_1 on 2022-07-28. Score: 3 | Accepted answer

There are two methods to do this: ZMQ and Tracepoints.

The `zmqpubsequence` can be used to notifications for all mempool events. See the [PR](https://github.com/bitcoin/bitcoin/pull/19572) and [test](https://github.com/bitcoin/bitcoin/blob/master/test/functional/interface_zmq.py#L292) for more information. It was designed specifically for the mempool mirroring use case.

The other method is tracepoints, but this requires applying a currently [draft PR](https://github.com/bitcoin/bitcoin/pull/24935). Tracepoints work similarly to ZMQ in that your program will use a tracepoints interface and wait for notifications.

> **Comments:**
> **username_1**: @1440000bytes Good point, forgot that `zmqpubsequence` was added. I've updated the answer.  
> **username_2**: I you want a project example which keeps a continuous updated copy of a mempool you can check https://github.com/mempoolexplorer/mempoolexplorer  

---

