main: make /gen actually mine

[ericscalibur]

nMineMode defaults to MINE_RELAY (0) and ParseStartupArguments() never changed it, so a node started with /gen would spawn ThreadBitcoinMiner, enter BitcoinMiner(), hit

if (nMineMode == MINE_RELAY)
    return true;

and return before doing any work. The node then ran indefinitely looking completely healthy -- it synced, it held peers, it reported no errors -- while earning nothing. Nothing in the log said otherwise; the only hint was nMineMode = 0 in a startup line that reads like a status echo.

This affects every headless miner, because the GUI is the only other way to select a mining mode.

/gen now implies MINE_SOLO unless /operator or /participant asked for something else. Verify with nMineMode = 1 at startup.

[Bitflash-sh]

Confirmed, and it is worse than the description claims — I found this running against our own infrastructure while reviewing.

The bootstrap seed node on our VPS has been up for 15h28m with -nogui -debug -gen. Its log:

nMineMode = 0, strParticipantPool = , fGenerateBitcoins = 1

BitcoinMiner started appears zero times, and the process sat at 8.7% CPU — RandomX in fast mode pins a core. It mined nothing for over fifteen hours while every other signal said it was healthy. Exactly the failure mode you describe.

Verified your fix on a clean datadir:

nMineMode = 1, strParticipantPool = , fGenerateBitcoins = 1
[net] BitcoinMiner started
RandomX: dataset ready (fast mode active)
[net] BitcoinMiner: mining with RandomX (fast 2GB)

This is a regression, not a long-standing gap. I bisected it to 294d8f7, the refactor that introduced mining modes, first shipped in v1.2.0. Before that commit /gen only needed to set fGenerateBitcoins, because BitcoinMiner() had no mode gate to return at. So every headless miner from v1.2.0 through v1.2.4 has been mining nothing. GUI users were unaffected — the interface sets a mode explicitly — which is why this went unnoticed for four releases.

On the patch itself: placing it inside the /gen branch and guarding on nMineMode == MINE_RELAY is the right call. /operator and /participant are parsed after it and still win, so -gen -operator correctly stays MINE_OPERATOR. Minimal and in the right spot.

One note, not a change request: /solomine alone still leaves fGenerateBitcoins at 0, so it never spawns the miner thread. That reads as intended — it is a modifier for the peer-wait check, not a mode selector — but it means -solomine without -gen is silently inert. Separate concern from this PR.

Reviewed clean. Nice catch, and thank you for writing it up with the log line that gives it away.

[Bitflash-sh]

Shipped in v1.2.5, along with #41 and #43. Thank you — three PRs, three real bugs, and the diagnosis was right in each one.

#42 got top billing in the release notes. It deserved it: four releases of headless miners earning nothing with no way to tell, and our own bootstrap seed was one of them.

Verified on the merged tree before tagging, both platforms:

nMineMode = 1, fGenerateBitcoins = 1
[net] BitcoinMiner started
[net] BitcoinMiner: mining with RandomX (fast 2GB)

One thing your report led to that is worth flagging, since it is the same shape as the bug you found. #5 was a Linux segfault while syncing — root cause was %I64d, an MSVC-only specifier that glibc mis-parses into a pointer dereference. GCC had been reporting it the whole time and -w was swallowing it. But removing -w alone changed nothing, because every format string here goes through strprintf / error / OutputDebugStringF and none carried a format attribute, so the compiler never inspected a single one. Both are fixed in #44 — that class of bug now fails the build instead of shipping.

Three of your four findings share a root: something was broken and nothing said so. Worth keeping in mind if you keep looking around this codebase — silence is where the bugs are hiding.