Proposed efficient getblocktemplate replacement

[gandrewstone]

Bitcoin Unlimited is proposing a replacement for getblocktemplate that sends block candidates in O(log2(blocksize)). It does this by not providing every transaction in the block. Instead it gives the mining pool the block header and the merkle branch to the coinbase transaction (similar to stratum). Two new RPC commands are defined, getminingcandidate and submitminingsolution. To make it extremely easy to integrate into your pool, these RPCs use same json-rpc protocol as getblocktemplate/submitblock, and the same RPC parameters where possible. For example, the header returned from getblocktemplate is formatted very similarly to getblock, and the return (error) values for submitminingsolution are the same as submitblock (plus one additional error).

Please take a look, give feedback, and hopefully you can integrate this RPC into your pool so that large blocks can be communicated efficiently between bitcoind and the pool.

https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/1139

Documentation: First section of: https://github.com/gandrewstone/BitcoinUnlimited/blob/minerRpc/doc/miner.md

[YihaoPeng]

This is very similar to the lightgbt we introduced into Bitcoin ABC (currently only in our own branch). https://github.com/btccom/bitcoin-abc-1/commit/e87774c8ee724a0e9ecbc289236920ea1aa04a83

This branch of BTCPool contains the support of lightgbt. It may only need a small modification to compatible with BU. https://github.com/btccom/btcpool/tree/lightgbt

[jtoomim]

It appears that the getminingcandidate RPC does not allow the caller to specify how much space to reserve for the coinbase transaction. While this will not harm most pools, p2pool uses a coinbase transaction that often exceeds 2 kB in size, and occasionally exceeds 8 kB. This can cause the coinbase transaction to push the total block size above the consensus limit (e.g. 32 MB) and make a block invalid. It would be nice if an optional argument specifying the reserved space for the coinbase transaction could be added.

That said, p2pool would need some large changes before it could use this interface, so this maybe isn't a priority.

[SwimmingTiger]

@jtoomim There is a workaround to set the generated maximum block size in the bitcoin node's configuration file to be less than 32MB. For example, set to 31MB, this is equivalent to reserve 1MB space for the coinbase transaction.

[jtoomim]

@SwimmingTiger That workaround does not work properly programmatically for cases in which the coinbase transaction varies in size from hour to hour or day to day. As such, p2pool users would need to reserve an excessive amount of space for the coinbase in order to prevent an increase in p2pool users from bloating the coinbase and pushing it over the threshold. Accepting an argument from the caller of getminingcandidate is a much better solution to the problem, and not particularly complicated to implement, and I thank BU for adding it.