Code review ACK, but there is a functional change: with this code the internal miner will never search the nonce space above 0xfff.

Also: how did you test this?

We discussed this in #4793 . @sipa said in some outdated commit that removing if ((nNonce & 0xffff) == 0) was safe but I can't remember the reason why it was that if instead of the later if ((nNonce & 0xfff) == 0) what can be removed.
Now that you're saying it I think it is a mistake and what can be removed is just:

if ((nNonce & 0xfff) == 0)
    boost::this_thread::interruption_point();

@gavinandresen I haven't tested, but it's just ScanHash that returns after 0x1000 iterations - the mining loop continues with the same nonce until 0xffff0000 is reached (which could actually become 0xfffff000 then, but who cares).

Tested ACK: adding a LogPrintf("Nonce: %x\n", nNonce); in the loop that calls ScanHash, and running setgenerate true in -testnet mode confirms higher nonces are being tried.

Oh, here it was the missing piece of earlier conversation: jtimon@9d12ff7#diff-4a59b408ad3778278c3aeffa7da33c3cR384

@luke-jr this is mining related, can you ACK?

ACK, only tested on regtest since testnet-in-a-box style apparently refuses to mine in master... :/

ACK on testnet via gdb testing

Better is better... so ACK.

But after removing the hashmeter, and assuming we no longer care about performance of the CPU miner (we don't) it looks to me like the code could be simplified a lot by getting rid of ScanHash and just having the mining loop be:

   while true:
       ... create block...
       ... serialize header without nonce..
       set nonce to zero
       do:
           compute hash with nonce
           ++nonce
           if hash <= target: BLOCK FOUND
           if nonce%0xfff == 0 : interruption point
        while nonce < 0xffffffff
        Increment extraNonce
  end while true

Yes, more simplifications can be done later.
This is what I had in mind for next steps: jtimon@a029a67
jtimon@da36fb5
Different things can be done (my preference is that we share as much code as possible with regtest, optimizing only for regtest), but most of the options I have considered imply the removal of the hashmeter as a first step, so here it is isolated from other decisions that people seem to care less about.

ut ACK.

lovely to have this part of the code simplified.