Remove internal miner

[Leviathn]

This code removes the internal miner which is only useful on Testnet.
This leaves the internal miner that is useful on RegTest intact.

[TheBlueMatt]

ACK 8d1de43

[sipa]

Why? Having a builtin miner was tremendously useful when experimenting with segnet.

[dcousens]

ACK. But this was useful when testing Segnet.

I guess this marks the official end of an era? Haha.

[TheBlueMatt]

@sipa Meh. Its really trivial to go git clone some CPU miner and point it to bitcoind...we dont need an entirely-unmaintained CPU miner in the codebase when we have a separate (?!) codepath for mining on regtest. If someone feels like merging this codepath and regtest, I'd be more happy, but having two separate built-in miners seems like overkill.

[sipa]

Feel free to go merge the codepaths then, or add a simple python based RPC miner instead. But I disagree with not being able to actually create valid blocks at all.

[wtogami]

https://github.com/pooler/cpuminer
Much faster than the internal miner. Supports GBT.

[luke-jr]

BFGMiner also has CPU mining support FWIW.

[sipa]

Well at the very least, remove the restriction that generate can't be called on anything but regtest, and make it not stick in an infinite loop if no match is found after 2^32 attempts.

[sipa]

I agree with removing the duplicated code path, by the way. We wanted to do that when the regtest-specific behaviour of setgenerate was factored out into its own RPC, but we didn't want to make large changes at the time.

[pstratem]

Tested ACK

8d1de43

[paveljanik]

ACK Leviathn@8d1de43
Great diffstat statistics, BTW ;-)

[paveljanik]

NITS: please remove some git grep BitcoinMiner occurrences:

doc/developer-notes.md:- BitcoinMiner : Generates bitcoins (if wallet is enabled).
src/miner.cpp:// BitcoinMiner

Few more lines to be deleted...

[laanwj]

I tend to agree with this on the longer term.

However, before this can be merged, there needs to be an easy to compile and set up CPU miner (let's say a "reference miner"). As well as instructions in doc/ for setting this up instead (as migration path for people using the internal miner).

Last time this was proposed, that was far from the case. I tried various project that were proposed to be as alternative but they were professional miner tools with lots of setup options, or a tangled web of dependencies.

So that's the condition.

[gmaxwell]

I argued pretty vigorously against this before in that I feel that Bitcoin Core should be "complete"-- that sending people off to weave together many programs to build a functioning system was not in the sincere spirit of decentralization. Today testnet is not really cpu minable and we have the regtest miner. So I'm increasingly feeling this is a principled distinction with no practical impact.

I think Wladimir's call for an easy to setup cpu miner and clear docs is good; and perhaps the best remediation possible given the facts we can't control.

[luke-jr]

./configure --enable-cpumining
make
./bfgminer

[laanwj]

@luke-jr As a reference miner, that's like swatting a fly with a thermonuclear missile. Checking it out is like downloading an operating system. I'd prefer something minimal and self-contained that people can more easily study.

[sipa]

So if you would:

• Keep deleting all code that this PR currently deletes
• Remove the restriction that the generate RPC only works for regtest
• Fix the bug that generate will go into an infinite loop when it needs to check more than 2^32 hashes, or even better add a timeout and allow it to fail.

That means that instead of bitcoin-cli setgenerate true, you could use while true; do bitcoin-cli generate 1; done, with nearly no loss of functionality.

[pstratem]

@sipa that seems reasonable, but changing the behavior of the generate rpc probably belongs in a new pr

[laanwj]

I'm not sure about @sipa's solution. It is elegant because it removes duplicated code, but on the other hand I dislike a RPC call that can hang for a long time. This holds up a (precious) RPC thread instead of a dedicated mining thread. With a timeout (or "max iter count") it would certainly be acceptable to me though.

But as you would effectively still need an external script to mine testnet, to keep calling generate after every timeout, instead of just pass -gen=1 and forget. I'm not convinced that this is better than a completely external reference miner. Easier to implement, sure.

Edit: I've talked with @sipa on IRC and he convinced me that this is the way to go. Our 'reference miner' (for testnet) will just be a python script that calls generate in a loop.

[laanwj]

@Leviathn are you going to move this forward according to sipa's comment?

[sipa]

See #7663.