Tracking: Official support for mining RPCs in Zebra

[mpguerra]

Motivation

We want to officially support mining functionality in zebra by making it available on the stable Zebra docker image.

Before we are comfortable doing this we might want to do some of the following:

Scope

Making getblocktemplate-rpcs a default feature

• Remove extra tests for getblocktemplate-rpcs feature #7362
• Make getblocktemplate-rpcs a default feature #7361

Potential security issues

• getnetworksolps & getnetworkhashps RPCs hang with large num_blocks #6688

Related work

• devops: Remove redundant tags in Docker Hub #7415

Optional

Performance improvements

• Automatically verify transactions in blocks when the same transaction is already in the mempool #5674
• Send the same getblocktemplate RPC response until the template would change #5604
• Detect mempool changes for getblocktemplate long polling with a channel #5891
• Make getnetworksolps & getnetworkhashps RPCs more efficient by caching difficulties and times #7403
• Don't return from long polling if the block template is an invalid block proposal #6037
• Verify proposals are valid after sending them to miners #6047

Usability

• getblock: return the valuesPools and chainSupply fields #5449
• Support shielded coinbase in getblocktemplate for Sapling addresses #5472
• Reduce Zebra disk usage for mining pools #5718
• Store the serialized block size in the database #5911
• Fix future compatibility of address RPCs with unknown unified receivers #6193
• Implement getnetworkinfo RPC so the default s-nomp config works #6082
• Add startingheight field to getpeers RPC #6068
• Support shielded coinbase in getblocktemplate for Orchard Unified addresses #5929
• Log a warning when the loaded config includes fields used by elasticsearch feature #7118 no longer related

Tech debt

• Simplify z_listunifiedreceivers RPC implementation #6190

This is an exhaustive list that will need to be triaged and prioritised further.

[teor2345]

• Don't return from long polling if the block template is an invalid block proposal #6037
• Verify proposals are valid after sending them to miners #6047

These aren't related to performance, they are for detecting bugs in our proposal construction.

But since we haven't seen any invalid proposals for a long time, I think we should close these tickets, and open tickets for any specific proposal bugs that actually happen.

[teor2345]

• Simplify z_listunifiedreceivers RPC implementation #6190

I think these cleanups can be turned into TODOs in the code instead, and we can fix them if we modify that code in future.

[teor2345]

• Log a warning when the loaded config includes fields used by elasticsearch feature #7118

This is a usability issue, not really technical debt. Currently Zebra panics, which is ok, but warning and ignoring the unused config fields would (possibly) be better for some users.

The drawback is that users who expect Zebra to fail if the Zebra version or config is wrong will be surprised.

[mpguerra]

• Simplify z_listunifiedreceivers RPC implementation #6190

I think these cleanups can be turned into TODOs in the code instead, and we can fix them if we modify that code in future.

I'm thinking this will require a PR and review cycle anyway (albeit a shorter one than actually fixing it) and will therefore languish in our backlog as a result

[teor2345]

• Simplify z_listunifiedreceivers RPC implementation #6190

I think these cleanups can be turned into TODOs in the code instead, and we can fix them if we modify that code in future.

I'm thinking this will require a PR and review cycle anyway (albeit a shorter one than actually fixing it) and will therefore languish in our backlog as a result

I honestly don't think it matters either way. We might be more likely to do the change if there's a TODO near the code we're modifying anyway. But since it's not an important change, it doesn't really matter how likely we are to do it.

[mpguerra]

We are done here for now 🎉