Add a manually-triggered workflow for mining a block on testnet

[teor2345]

Motivation

We want to add a workflow to Zebra that:

1. Only runs when a developer manually triggers it
2. Launches a new zebrad node on testnet
3. Launches a mining pool or solo miner to connect to zebrad
4. Waits for zebrad to sync
5. Mines a block
6. Fails if no blocks are mined, or if the mined blocks are invalid, or if the miner has RPC errors

We also want to add this workflow to the release checklist, to make sure we haven't broken miner support.

Complex Code or Requirements

We'll need enough RPCs implemented to run the mining software, and we need to fix all the RPC bugs and incompatibilities.

Testing

We'll need to run the workflow manually a few times before merging the PR.

Timing

We're going to limit this ticket to 2 days of work, because it won't be usable in production. (We had to disable parts of s-nomp because it doesn't support NU5.)

Related Work

Create a Docker image for mining on Testnet with Zebra:

• Create a Docker images and docker-compose for mining with Zebra on Testnet #6118

Check that a miner can connect to Zebra, but don't wait for the sync, and don't mine any blocks:

• Check that mining pool software can connect to Zebra in CI, but don't mine any blocks #5304

[mpguerra]

This should probably be the last issue we work on as part of the GBT work

[mpguerra]

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

[upbqdn]

A prerequisite for this issue is to find a suitable miner that would run in the CI.

[teor2345]

A prerequisite for this issue is to find a suitable miner that would run in the CI.

I think nheqminer should work in CPU mode, following these instructions:
https://github.com/ZcashFoundation/s-nomp/blob/zebra-mining/zebra-instructions.md

It is relatively cheap to mine on testnet, the difficulty is around 1-5 CPU cores most of the time.

[mpguerra]

I think this issue is a nice to have so let's timebox it to a couple of days

[teor2345]

Is this a low priority or optional ticket?

[mpguerra]

Is this a low priority or optional ticket?

Depends on:

• how useful the team thinks it will be
• how often we will use it
• what the maintenance burden (if any) will be (I guess this will be mitigated by having a Docker image)

We may also decide to make #6118 the same priority as this one, e.g if this is optional so should #6118 be

[teor2345]

Is this a low priority or optional ticket?

Depends on:
* how useful the team thinks it will be
* how often we will use it
* what the maintenance burden (if any) will be (I guess this will be mitigated by having a Docker image)

We may also decide to make #6118 the same priority as this one, e.g if this is optional so should #6118 be

If miners are using Zebra in production, we'll need to test the mining RPCs work before we do each release. (Because we're not doing integration testing with every PR.) So I think this workflow is actually a blocker for mainnet mining in production.

Otherwise, we could accidentally release a RPC bug, and miners would lose money and stop using Zebra.

For example, we recently released a lightwalletd bug into production that we claimed we'd fixed, because no-one tested the PR with that fork of lightwalletd. So this is reasonably likely to happen if we don't have a mining workflow.

[teor2345]

@mpguerra did you want to reduce this estimate now we have split the docker image into #6118?

[mpguerra]

@mpguerra did you want to reduce this estimate now we have split the docker image into #6118?

Sure

[teor2345]

I don't think this ticket is a medium priority any more, our tests seem fine without it.