Support long polling in the getblocktemplate RPC (excluding mempool changes)

[teor2345]

Motivation

Some mining pools need long polling support, where the RPC response is delayed until the block template changes.

Specifications

https://en.bitcoin.it/wiki/BIP_0022#Optional:_Long_Polling

Designs

RPC fields:

• Declare longpoll support in the getblocktemplate RPC capabilities
• Provide a longpollid field in the RPC response, which represents the contents of the tip and mempool used to create the response.
• Accept a longpollid parameter to the RPC request,
  • which activates long polling until the ID changes.

When long polling is requested by the client using a longpollid parameter, delay the RPC response until:

• the tip block changes:
  • add a submitold: false field, because the old template is invalid, and
  • use a ChainTipChange watch channel that is updated by the state;
• any transactions in the mempool change:
  • add a submitold: true field, because the old template can still be a valid block, and
  • use a watch channel that is updated by the mempool, like ChainTipChange;
• or the max_time is reached (or close?):
  • add a submitold: false field, because the old template is invalid.

RPC server:

• Increase the default number of RPC threads when the getblocktemplate-rpcs feature is on, because every long polling client could use one thread.
  • Test the jsonrpc_core implementation to see what happens when a RPC request future is held open. (We assume it will do whatever the underlying tokio executor does.)

Testing

I have tested long polling with zcashd, and it works with this command:

 zcash-cli getblocktemplate '{ "longpollid": "0000000000ab159b36911c7860f637a8e5c2d99d17c2a922029ff0905655a30080497" }'

[mpguerra]

We probably want to do this, however, this seems like a nice and should wait until we have the basic MVP functionality done (Scope section in #5234)

[teor2345]

We probably want to do this, however, this seems like a nice and should wait until we have the basic MVP functionality done (Scope section in #5234)

How will we know our MVP implementation actually works, if we don't implement enough functionality for a mining pool to run it?

[mpguerra]

Hey team! Please add your planning poker estimate with Zenhub @arya2 @conradoplg @dconnolly @oxarbitrage @teor2345 @upbqdn

[teor2345]

This is potentially a very large ticket, and it's in this sprint, so I'm going to split the mempool part into another ticket.

[teor2345]

This is potentially a very large ticket, and it's in this sprint, so I'm going to split the mempool part into another ticket.

The specific split I planned didn't end up working out, so I closed that ticket, and I did it in multiple PRs instead.