CPU Mining on Testnet (sic!) #5742

All right folks, here's one more. Start from scratch on testnet. Set gen to 1. Result:

ERROR: ContextualCheckBlockHeader : forked chain older than last checkpoint (height X(5, 17, etc...)) terminate called after throwing an instance of 'std::runtime_error' what(): CreateNewBlock() : TestBlockValidity failed

Pretty self-explanatory.

main.cpp ln: 2597

// Don't accept any forks from the main chain prior to last checkpoint
CBlockIndex* pcheckpoint = Checkpoints::GetLastCheckpoint();
if (pcheckpoint && nHeight < pcheckpoint->nHeight)

2597: return state.DoS(100, error("%s : forked chain older than last checkpoint (height %d)", func, nHeight));

Call stack:

0 ContextualCheckBlockHeader main.cpp 2597 1 TestBlockValidity main.cpp 2774 2 CreateNewBlock miner.cpp 335 3 CreateNewBlockWithKey miner.cpp 411 4 BitcoinMiner miner.cpp 468 5 boost::_bi::list1boost::_bi::value<CWallet* >::operator()<void ()(CWallet), boost::_bi::list0> bind.hpp 253 6 boost::_bi::bind_t<void, void ()(CWallet), boost::_bi::list1<boost::_bi::value<CWallet> > >::operator() bind_template.hpp 20 7 boost::detail::thread_data<boost::_bi::bind_t<void, void ()(CWallet), boost::_bi::list1<boost::_bi::value<CWallet> > > >::run thread.hpp 117

This affects mainnet too, and results in the daemon crashing any time you try to mine a checkpointed block.

So the user is trying to generate bitcoins before he finished IBD/before the last checkpoint defined in the source. In such case, I'd simply catch all exceptions...

What about this?

diff --git a/src/miner.cpp b/src/miner.cpp
index e359654..403ec9a 100644
--- a/src/miner.cpp
+++ b/src/miner.cpp
@@ -530,6 +530,10 @@ void static BitcoinMiner(CWallet *pwallet)
         LogPrintf("BitcoinMiner terminated\n");
         throw;
     }
+    catch (const std::exception& e)
+    {
+        LogPrintf("BitcoinMiner terminated\n");
+    }
 }

 void GenerateBitcoins(bool fGenerate, CWallet* pwallet, int nThreads)

@paveljanik Long term, a more nuanced solution is needed. Of course, revisiting checkpoints in the future will inform the direction. I'd love to see consensus on a backlog/brainstormlog in the source tree.

Checkpointing a non-existent block hash as block 1 (to fork yourself), and changing one of the pchMessageStart bytes will prevent you from syncing the blockchain. The second part should prevent connections since the client will download any valid fork it can find.

2015-02-07 09:25:19 ERROR: ContextualCheckBlockHeader : rejected by checkpoint lock-in at 1 2015-02-07 09:25:19 Bitcoinminer terminated due to checkpointed block keypool return 3

So I tried this patch, it lets the miner die, but getgenerate still returns true, gethashespersec returns 0,

without it you get this on the CLI: $ bitcoin-cli getinfo $ bitcoin-cli setgenerate true $ terminate called after throwing an instance of 'std::runtime_error' what(): CreateNewBlock() : TestBlockValidity failed

debug.log: you get this just before it dies. 2015-02-07 09:30:09 CreateNewBlock(): total size 1000 2015-02-07 09:30:09 ERROR: ContextualCheckBlockHeader : rejected by checkpoint lock-in at 1

@afk11 Mining prior to the last checkpoint (for as long as they exist) is futile (or worse), and so is prior to the sync, practically speaking. A patch must account for the former, and probably should for the latter.

I agree. The patch above doesn't go far enough since the client still thinks the thread is running.

Prior to checkpoints - yes it should always forbid any mining while there are still checkpointed blocks that haven't been synced, as mining is useless in this situation.

But beyond the last checkpoint and prior to syncing everything, is slightly less of an issue. It won't hit this specific error, and if they're lucky they'll outdo everyone else ;).

Should be fixed by #6123

Excellent.

Related #5987.