expose fees via ZeroMQ for transactions in the mempool #11848

This is a feature request:

Would it be possible to expose fees for the transactions in mempool via ZeroMQ? getmempoolentry already shows fee for a tx in the mempool, could this be exposed via ZeroMQ as well? e.g. with the 'rawtx' event?

Thanks!

Hello, edited the request, I was refering to RPC/REST but what I really need is ZeroMQ.

rawtx message is just that, a raw transaction so NACK to that.

See #8549.

e.g. means for example ... sure rawtx is a rawtx, and hashtx is hashtx.

Would a new event that has the fee for a tx from the mempool be completely insane?

What you could do is fetch the transaction with getmempoolentry/RPC after you got the ZMQ message? (push'n'fetch)

What would be the use case(s) to have the fee within the ZMQ message?

If it's just a change that speeds up your software, consider doing a local change.

Hi, yep I am using getmempoolentry/RPC after getting ZMQ message now in my app. Found a few days ago that I can do it that way. That is why I changed the description of the issue. It works well (still get some timeouts though).

Is it not easier to expose that fee in a ZMQ event rather than do an RPC for every tx? I had cases when RPC-ing kileld bitcoind -> #11368. I beleive the whole point of ZMQ being in core is to minimize RPC where possible - but I can be wrong here.

I am asking, as I do not know the answer here ...

Usecases that I can think of:

• bitcoin-qt to show average fee using ZMQ messages, basically without blocking bitcoind - but perhaps it has a way of doing it another way

• it could make showing real-time fees easier for other services, like block explorers, etc.

• e.g. electrumx server could use ZMQ to get those changing fees and perhaps let the clients directly listen to them, again helping to see the underlying market in action, without much of a hastle as ZMQ is really lightweight and can leave processing for the clients (doing averages, etc. , even letting new estimation algorithms to be implemented on non core wallets)

I am not sure why we do not see more of services showing transactions and their fees in real-time, but perhaps doing ZMQ + RPC to get the information is one of the reasons (or just cause no body cares). I think one of the problems with high fees is that people do not really look at the price, they do not "feel" it is a changing thing. If we expose that to people, they can see the fees are dynamically changing and there is a market. Perhaps it could motivate them to not just blindly follow the calculation of wallets (lot of them advise too high fees), but check for them selves at a real-time fee showing service to have an idea what are the fees per TX. (Ideal would be to see that in their own wallet)

Right now the fee market is not as affective as it could be, as the users mostly do not know of the underlying market. Perhaps, because it is not visible, they are used to real-time price updates from stock markets, etc. Could be an easy way to show them the market exists without doing much education.

The problem is that ZMQ is not a reliable transport - it does not guarantee you're not missing anything. That means that if you really want to see all transactions, you must additionally rely on RPC anyway. This is one of the reasons for not providing too much information through ZMQ itself, as it is more useful as a notification mechanism "there are things you may want to look at" than an authoritative source of information.

yep I am using getmempoolentry/RPC after getting ZMQ message

Do you call getmempoolentry right after receiving the zmq message? Or do you enqueue the message so you process those in the right pace?

I have a queue, when the promise resolves (RPC) it is exposed as an event to a websocket for the client to process.

Thanks @sipa, @promag & @jonasschnelli for your time explaining. It seems ZMQ in combination with RPC is the ideal solution. I will close the issue.