Disable mining on nonrelease branches. #8101

In order to make it safer to merge consensus changes, we should disable mining via RPC on nonrelease branches.

This would have an undesirable effect on testnet.

@btcdrak This PR only has an effect on mainnet.

Assuming that miners runnning master already have their own patch set, how would this prevent them from creating a toggle-fDisableMiningOnNonreleaseBranches-patch?

I'm not sure how efficient this change is. fDisableMiningOnNonreleaseBranches could be an additional obstacle for mining pools running patches/extended versions of core. Sure, they could just pass in a CLIENT_VERSION_IS_RELEASE but would this be the appropriate (patch Bitcoin Core, flag it as CLIENT_VERSION_IS_RELEASE)?

I think @sipa's idea of not adding the soft fork to the mainnet parameters is better so I'm closing this.

Assuming that miners runnning master already have their own patch set, how would this prevent them from creating a toggle-fDisableMiningOnNonreleaseBranches-patch?

Nothing does. But apparently people randomly check out Bitcoin Core without being aware of the risks of mining on master. Requiring an explicit source code change (especially if the source is commented as to why) puts up a stupidity barrier there.

Sure, but the same is a barrier to test mainnet-mining on master: E.g. "Let me quickly check if this bug is in master, too" or "Let's see if I need to change my workflow for the next bitcoin release by checking if current master breaks anything"...

It should be common sense that running bitcoin (especially master) could lead to monetary losses and adding such checks is just a unnecessary bloat of CChainParams and code in general. Otherwise, we could as well open pulls for "Disable wallet on nonrelease branches", etc.

I see that the intention of the pull was to make it "safer to merge consensus changes", but I think we should never merge consensus changes that could cause undesired behavior/hard-/soft-forks.