Subject: [bitcoin-dev] Trying to patch Core ZMQ "rawtx" topic to only publish unconfirmed transactions: How?

From: Ali Sherief <[email-masked]>
Date: Fri, 26 Nov 2021 16:56:48 +0000

This has also been posted on Bitcointalk forum: https://bitcointalk.org/index.php?topic=5373341.msg58539261#msg58539261 I have republished it here hoping someone more knowledgeable can post some insight about this.
----
It appears that the ZeroMQ topic I'm listening to, "rawtx", not only emits a raw transaction when it appears on the mempool, but once it's already confirmed too.

This messes with my software, causing it to add txids, addresses, etc. a second time inside arrays (this means that the same transaction is received twice in total).

Array de-duping is not a viable solution long-term (because the array will quickly grow to be big eventually and then this has to happen every time a new element is added), so I'm trying to nip the problem from the source by instructing Core to only publish unconfirmed bitcoin transactions.

According to https://bitcoin.stackexchange.com/questions/52848/is-it-possible-to-configure-the-bitcoin-daemon-to-only-broadcast-unconfirmed-tra , it is not possible to configure this from a configuration or command-line option. The source code must directly be edited. But since the codebase has changed greatly, the proposed solution no longer works.

----

So basically, I know that something inside src/zmq/zmqnotificationinterface.cpp needs to be patched, but I'm not sure which function, or how to do it. Because I only need unconfirmed transactions to be published on ZeroMQ rawtx and not confirmed ones, it's one of the following functions that I need to patch for my own build:

CZMQNotificationInterface::TransactionRemovedFromMempool
void CZMQNotificationInterface::BlockDisconnected

Both of these call NotifyTransaction() method which I assume fires a message on "rawtx" channel.

In the Stack Exchange question I linked above, Jonas Schnelli suggested adding an `if (!pblock)` check, but that was several years ago and the function he was referencing no longer exists.

But I still wonder if the pblock check is still applicable in the present day (i.e. if it's indicating a block the transaction is inside).

- Ali Sherief