Add JSON push notifications? #1897

Currently if one wants to get info about what is happening in bitcoind, one needs to poll various parameters - checking the balance per account, checking for new transactions and so forth.

I propose adding some JSON push notifications coming from bitcoind to some predefined http address. This approach would let one's application communicating with bitcoind to know about all the latest events from the program without having to poll it often. Some sample notifications could include:

• New Tx appearing in the wallet with 0, 6 and other number of confirmations
• New block appearing in the blockchain
• A block being replaced in the blockchain
• Balance changing in some account with 0, 6... confirmations

This is one of the goals that I had in mind with the "uiInterface" design. It is possible to install listeners for signals such as "new transaction" or "transaction status changed" in a decoupled way.

This is currently used to send updates to the GUI, but handlers could be added to trigger JSON push notifications and such.

New block / block being replaced is already there, see the -blocknotify command-line/bitcoin.conf option. It is trivial to combine it with curl to get a "send block information to a URL when there is a new block."

With some programming you can keep track of 1/6-confirm transactions using it.

For monitoring transactions, -txnotify would be easy but forking a new process every time there is a new transaction is almost certainly not the right way to go, but maybe it would work if it was rate-limited to only notifying at most once every N seconds.

I wrote a monitorblock/tx patch a long time ago, but fell out of love with it-- it was a lot of extra code to maintain, and it is really easy to get feature creep (if you support notifying https: URLs then you suddenly have to deal with certificate chains and expired certificates, you have to figure out what to do if there is an error communicating with the website, etc etc).

The bloom filter work that is just about ready to merge is also very relevant.

PS: we need some good example of using -blocknotify to keep track of 1/6/double-spent transactions, a little 'watchconfirmed.py' in contrib/ would be nifty.

Agreed, I think putting outbound JSON notification itself in the core is overkill. If we had something lightweight, like a socket that you could connect to where you get a packet when an event happens, that'd be just as useful (and more versatile than launching a command). A simple Python script could connect to it and handle dispatching in any simple or complex way the user wants.

This could be added to the current HTTP server. Just request GET /events, and it opens a stream where you get notifications of events {"event":"balancechanged","balance":"123456"}... etc, useful, minimal and simple as cake to implement.

JSON-RPC 1.0 was bidirectional, so would have fit well. Unfortunately, that functionality was removed in 2.0. I have a pullrequest for GBT longpolling open, but I don't know how well it would work for events in general (seems too easy to miss an event). Chunked encoding could be used to simply stream data, but I think most clients won't give you anything until it's all received. Not sure how complex websockets are...

We're not going to invent another protocol for this.

If HTTP JSON-RPC longpolling does not provide a solution, then the stratum protocol would be the next natural community-adopted candidate. Line-based JSON-RPC, whether client or server may send asynchronously, seems a fair match.

Who is inventing a protocol here? @luke-jr I don't like longpolling. IMO it's kind of a hack, as you have to re-establish the connection every time.

I'm not sure about "most clients", but streaming JSON data over a HTTP connection works fine at least in Python. If you can receive streaming video then you can receive streaming everything...

Adopting the Stratum protocol sounds like overkill... We don't need an alternative method to submit commands or receive replies, just a way to remotely listen to async events so that UIs can be updated and such.

stratum has nothing to do with protocol buffers. It is a protocol that is less complex than HTTP, even:

C: JSON-RPC \n
S: JSON-RPC \n
C: JSON-RPC \n
S: JSON-RPC \n
S: JSON-RPC \n

No HTTP headers, no HTTP chunking, etc. Very simple and easy: just text lines of JSON. Client or server may send a line at any time.

So is there any progress on this? It would be a huge improvement to make automated payment systems with bitcoin since that'd reduce amount of polling required to process transactions.

Likely this will never be implemented, as there are other ways to do notifications.

1. You can make your own push notifications by using the -*notify commands with a little Python (or shell) script:

 -blocknotify=<cmd>     Execute command when the best block changes (%s in cmd is replaced by block hash)
 -walletnotify=<cmd>    Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)
 -alertnotify=<cmd>     Execute command when a relevant alert is received (%s in cmd is replaced by message)

2. You could also help testing the ZeroMQ pull request, which provides a more flexible notification system: #2415

Closing this issue.