when i solo mine a block i see in debug.log
"Local has found possible valid block... queueing until timestamp is valid"
and the the whole client freezes, no more RPC requests are responded.. until
"Median Time between blocks is: 124 ... ProcessBlock: ACCEPTED "
so is there anything i can do against this? why cant i do "getinfo" etc..
does my pool software NOMP do anything wrong with the timestamps?
or is that the principle behind it:
if there would be a spike in hashrate ( 200% ), there will be 50% orphans ( as they all have to wait 45 seconds )
but how does difficulty then ever change?
I've been looking at my debug.log and see lots of this:
ERROR: CheckBlock() : block timestamp too far in the future
ERROR: ProcessBlock() : CheckBlock FAILED
GetNetworkHashPS(120)
GetTrueNetworkHashPS(120) - modified lookup
best index = 114672
difficulty = 0.435018
hashrate for section: 14.901249 MH/s, time diff = 1385421655 min
====difficulty change at block 114660
height = 114659, difficulty = 0.445892
hashrate for section: 15.959102 MH/s, time diff = 1385414455 min
====difficulty change at block 114600
height = 114599, difficulty = 0.457037
returning hashrate 241.250000 MH/s, lookup 15 (time difference = -0.0)
Ok so server time must be out of sync right? Well:
ntpdate pool.ntp.org
26 Nov 10:30:55 ntpdate[8366]: adjust time server 192.189.54.33 offset -0.102237 sec
0.1 seconds out of sync... umm does this time stuff cater for timezone?
ERROR: CheckBlock() : block timestamp too far in the future
ERROR: ProcessBlock() : CheckBlock FAILED
GetNetworkHashPS(120)
GetTrueNetworkHashPS(120) - modified lookup
best index = 114672
difficulty = 0.435018
hashrate for section: 14.901249 MH/s, time diff = 1385421655 min
====difficulty change at block 114660
height = 114659, difficulty = 0.445892
hashrate for section: 15.959102 MH/s, time diff = 1385414455 min
====difficulty change at block 114600
height = 114599, difficulty = 0.457037
returning hashrate 241.250000 MH/s, lookup 15 (time difference = -0.0)
Ok so server time must be out of sync right? Well:
ntpdate pool.ntp.org
26 Nov 10:30:55 ntpdate[8366]: adjust time server 192.189.54.33 offset -0.102237 sec
0.1 seconds out of sync... umm does this time stuff cater for timezone?
The default maximum wait is 45 seconds, but you can extend this if you want to for optimal acceptance rate.
In main.cpp on lines 2094 to 2107
Code:
else if(QDateTime::fromTime_t(pindexBest->pprev->pprev->pprev->pprev->GetBlockTime()).secsTo(QDateTime::fromTime_t(GetBlockTime())) < (60*10 + 45) && hashPrevBlock == pindexBest->GetBlockHash()) {
//A valid block has been found but the current network adjusted time will not permit it to be accepted by other peers
//Thus we hold the block until GetAdjustedTime() is such that if(GetBlockTime() > GetAdjustedTime() + 45) is false
printf("Local has found possible valid block... queueing until timestamp is valid \n");
//Since we know that GetBlockTime() is greater than GetAdjustedTime()
//We sleep the difference
//Doesn't hurt to check twice
if(GetBlockTime() > GetAdjustedTime() + 45)
Sleep(1000*(GetBlockTime()-(GetAdjustedTime() + 45)));
/*while(GetBlockTime() > GetAdjustedTime() + 45) {
//We wait here..
}*/
}
//A valid block has been found but the current network adjusted time will not permit it to be accepted by other peers
//Thus we hold the block until GetAdjustedTime() is such that if(GetBlockTime() > GetAdjustedTime() + 45) is false
printf("Local has found possible valid block... queueing until timestamp is valid \n");
//Since we know that GetBlockTime() is greater than GetAdjustedTime()
//We sleep the difference
//Doesn't hurt to check twice
if(GetBlockTime() > GetAdjustedTime() + 45)
Sleep(1000*(GetBlockTime()-(GetAdjustedTime() + 45)));
/*while(GetBlockTime() > GetAdjustedTime() + 45) {
//We wait here..
}*/
}
Change (60*10 + 45) to (60*10 + X)
Where X is the maximum amount of time you'd like to hold a block.
And recompile.
