Fix future time limit exception in cpuminer #18
Conversation
This wait already exists in GBT, need it in the cpuminer also
|
@cryptozeny Would you mind re-trying your test case with this? Previously I could reliably generate the error with 'generate 2 420000000', but I think you had a different scenario. |
but |
| // Not regtest: Wait until tip is 1 second in the past. | ||
| if (!Params().GetConsensus().fPowNoRetargeting) { | ||
| while (GetTime() - tip->GetBlockTime() < 1) | ||
| MilliSleep(50); |
There was a problem hiding this comment.
i just curious, why 50ms sleep?
There was a problem hiding this comment.
Good question.
First (in case anyone else is wondering), why wait at all? The reason is that in this reference code we don't want to do anything that could possibly create a block that an honest peer with an accurate clock would reject. If we generate a block with a time 1 second in the future, it may be received and rejected by such a peer before it is valid.
Why 50ms? Just to avoid a pegged loop. On average, this will require 10 checks before passing. Another option would be to wait on an event we schedule for the exact 1s mark in another thread.
What if I just recently moved my clock by setting it back by minutes or hours? Won't this potentially be a long wait? Answer: yes, if the network has been taken over by cheating miners making future blocks. You will be part of the solution by not building on the chain until it is valid, but there's more I'd like to see done in this area. When the local clock is adjusted by you or your automated agent, we should (possibly with your manual approval) roll the chain back to the last non-future block.
Will all this waiting cause the block production rate to fall? Answer: imperceptibly. Mining a block at 1 second is 11 trillion times harder than current difficulty.
11 trillion times harder than current difficulty? Won't that cause miners to disappear and mine something else until a few minutes later when this chain is more profitable? Answer: that's up to them. Simulation has shown the presence of this kind of hashrate makes blocktimes MORE stable. The reason is that it reduces lucky short blocks which would otherwise cause a big difficulty response, and encourages maximum hashrate after the block is late, reducing long blocks.
Ok but won't that cause more orphans if everybody is mining only around the same time? Answer: probably, it depends on the hashrate distribution. We need to keep an eye on this. The worst case is if there are 2 miners with a 50/50 split. I simulated this and found an average of 7 collisions within 1 second per 10,000 blocks. So far, in 2986 blocks on chain2, there has been 1 orphan.
|
1st try is ok
|
|
2nd ok
|
|
3rd ok
|
Running the cpuminer to find a block in the same second the tip was found would cause the default time increment (1 second in non-regtest) to kick in and violate the future time limit. The solution is to wait until that second has passed. This logic already exists in the GBT code path.