Dynamic configuration of ZMQ notifications #13850

Bitcoin's ZMQ notifications can currently be enabled (or not) through -zmqpub... startup arguments, but there is no way to enable more (or perhaps disable existing) notifications dynamically at runtime. This would be useful, so that software that wants to subscribe can configure the daemon accordingly (in conjunction with getzmqnotifications).

The most straight-forward way to implement dynamic addition of notifications is to add a new RPC addzmqnotification like this:

$ bitcoin-cli addzmqnotification pubhashtx tcp://127.0.0.1:5678
(returns the address, "tcp://127.0.0.1:5678")

This call would add a new pubhashtx notifier on the given address, either reusing an existing socket or creating a new one. This is very similar to how it could be created with -zmqpubhashtx=tcp://127.0.0.1:5678.

A potential difference to the existing CLI argument is that the RPC could, if desired, allow multiple pubhashtx notifiers on different addresses. Alternatively it could refuse to create a second one if one is already active and instead return the address of the existing one in that case.

There are two minor issues I have with this proposal:

1. It allows an RPC client to induce the daemon to start listening on an arbitrary address/port, which might be a security risk.

2. A ZMQ subscriber that wants to enable a certain notification probably doesn't care too much about the exact address/port, and might not want to be responsible for actually choosing one.

Issue 1) is IMHO not a big concern, as access to the RPC interface already allows a lot of things to be done and should be restricted anyway.

For 2), we could make the second argument of addzmqnotification optional or remove it completely. The address would then be chosen from an existing notification, or could perhaps be set using a generic -zmqaddress option; the RPC would return the chosen address. This would shift more sensitive configuration back to the startup options, while still allowing subscribers to dynamically enable the notifications they need.

What do you think about this proposal, does it make sense? Is there a better way to implement dynamic addition of ZMQ notifiers? (I know @promag is also interested in that - any input?)

I'm happy to work on a PR once it is clear what the interface should be (and that this is indeed actually desired).

I know @promag is also interested in that

Sorry I don't recall saying it, do you have a record?

Anyway I think if it should not be possible. For instance, it's not possible to dynamically add more RPC users — should it be possible? Beside, we use PUB/SUB which means that once the publisher is configured it can have multiple subscribers.

I know @promag is also interested in that

Sorry I don't recall saying it, do you have a record?

I don't remember exactly, to be honest (as this is already quite some time ago). But perhaps I was thinking of this comment at the time.

Anyway I think if it should not be possible. For instance, it's not possible to dynamically add more RPC users — should it be possible? Beside, we use PUB/SUB which means that once the publisher is configured it can have multiple subscribers.

The usecase I had in mind here are front-end applications that hook onto a Bitcoin Core daemon. If they need (for their particular situation) some ZMQ notification (e.g. block hashes), then they would be able to ensure that the currently running daemon supplies these notifications. Without that, those applications could just throw an error at the end user and ask them to manually update their bitcoin.conf.

So I think this is a different situation from dyanmically adding RPC users. Also adding multiple subscribers won't help, since the main reason for this feature is enabling (or disabling) notifications that are not turned on in the first place.

That said, I've not really had a strong need for this myself since when I opened the issue. So we can happily close it if that seems not like a useful feature to you and others.

since the main reason for this feature is enabling (or disabling) notifications that are not turned on in the first place

I'd say if there's the chance they are needed then they could be enabled in the first place.

since the main reason for this feature is enabling (or disabling) notifications that are not turned on in the first place

I'd say if there's the chance they are needed then they could be enabled in the first place.

That makes sense (and is definitely how it worked out in my own particular usecase). So let me close this.

(I'm still happy to work on implementing this in case it seems useful later, then feel free to reopen the issue.)