Add signal for name updates

[domob1812]

Bitcoin and, in consequence, Namecoin Core implement a rough "signaling" mechanism for new blocks, alerts and tx in the wallet (blocknotify, alertnotify and walletnotify). Very recently, they apparently also added a messaging system based on ZeroMQ.

Should we take advantage of this infrastructure and work on a way to get notification on name updates? This could be useful for things like NMControl that cache values. On the other hand, it probably only makes sense if one can explicitly specify the set of names one is interested in. Otherwise, just using the block notification is enough (except if one is looking for pending transactions).

Thoughts?

[phelixbtc]

The way I did it in the API server is very simple: clear the cache on a new block. RPC lookups are quite fast so this should be enough for most applications for the moment.

[JeremyRand]

I think it could make sense to allow signaling of new name transactions. This is useful in use cases where a large number of names are being watched, so that fewer name_show calls are needed on each new block. It's also useful for seeing pending name operations.

@phelixbtc How fast are name_show lookups in Namecoin Core? I'm skeptical that they're so fast that no users would want a signaling mechanism.

@hlandau I think you were talking about this functionality a while back. Can you comment?

[hlandau]

Please see https://github.com/hlandau/namesync.t/blob/master/doc/name_sync.md for the protocol I implemented for my namesync use case. It would be nice if whatever is implemented could support this.

[domob1812]

Yes, I recall that discussion - but I think this is something completely different than name signalling with Bitcoin's alertnotify-like method. And my opinion is still that such a mechanism should go into upstream Bitcoin first for something like UTXO syncing, if it is really needed.

[domob1812]

We should have this in the ZeroMQ interface. We likely need something like this (but probably slightly different) also for Chimaera, so I'll work on this at some point in time.

[domob1812]

The existing ZMQ interface from upstream Bitcoin supports four publishing methods: Blocks for a new best chain tip and transactions when added to the mempool, both just by hash or with the full data. As far as I understand, this is mainly meant for use cases where Bitcoin Core is run as a "border router" that pre-validates transactions/blocks and filters out potential DoS traffic.

The logical extension to names would be to define two new publishers nameonly and namefull. Whenever a name changes (registration/update is confirmed in the new chain tip, expires or a reorg "undoes" something) this is sent - in nameonly, just the name (as byte array) that changed is sent, so that subscribers can then use RPC or whatever else to update their data. With namefull, the name as well as its new data (value, address, expiration state - roughly what is returned from name_show) is sent.

This does not yet cover pending name operations, and it does not cover name_new's. I think that name_new does not need to be covered here at all - someone who really wants to listen for those can use the transaction-notifications from Bitcoin. Pending name operations may also not be very important - but we could have something like namepending, that just notifies the name whenever a transaction touching it is added to the mempool or such.

What do you think about this?

[domob1812]

@JeremyRand, what do you think about the proposal in my previous comment? Would that make sense? It will be useful to anyone who wants to maintain an external database of names; we will implement a similar interface for game states in Xaya (https://github.com/xaya/Specs/blob/master/interface.md), where this has already been discussed with future users.

[JeremyRand]

@domob1812 I've never actually used ZMQ (in Bitcoin Core or Namecoin Core), so I'll generally defer to you on this. That said, one interesting use case for this is that ncdns's certinject feature could be modified to be triggered by name_anyupdate transactions as they appear on the network. This would be useful because some certinject backends (especially NSS's sqlite mode) induce significant delay when injecting a cert, so it's less noticeable for the user if that happens before the user tries to visit the site. For certinject purposes I think we'd probably want to support pending transactions, since if a domain owner wants to revoke a TLS cert, we'd want the revocation to take effect immediately rather than waiting for a block to be mined.