I think "timestamp too early" problem is PoS problem. So Bitcoin won't be affected due to this.
[...]
NB: I am a newb to these things.
[...]
NB: I am a newb to these things.
I'm no expert either. This is like the first code I see since more than 8 years. I completely wasted my degree in computer science for other interests that didn't turn out to be career boosters at all, but that's another story
I'm getting very curious about how things work and I try to get some understanding. Even if it's far above my own level of comprehension, I give it a try :p
That being said, the link you gave me is an interesting post about this. I did look further and found out that this is not only a test run on POS coins. Bitcoin also has this check around lines 2559-2562 in main.cpp:
Code:
// Check timestamp against prev
if (block.GetBlockTime() <= pindexPrev->GetMedianTimePast())
return state.Invalid(error("%s: block's timestamp is too early", __func__),
REJECT_INVALID, "time-too-old");
if (block.GetBlockTime() <= pindexPrev->GetMedianTimePast())
return state.Invalid(error("%s: block's timestamp is too early", __func__),
REJECT_INVALID, "time-too-old");
I've also found coins, such as Nimbus, where for some reason they decided to comment out this check for POW and POS. This is apparently not a very good idea. Even bitcoin has newer blocks with earlier timestamps, which goes in against the logic. The protocol is designed to reject them.
I found this example on stackexchange:
Block #180966 with timestamp "2012-05-20 23:02:53" >> http://blockchain.info/block-height/180966
Block #180967 with timestamp "2012-05-20 23:02:13" >> http://blockchain.info/block-height/180967
This here ("Timejacking & Bitcoin") is an interesting article about timestamps and possible exploits if
not being taken care of correctly. Thus, removing the check is a no-go. Did nimbus ever block chain problems by ignoring the timestamp check? That's a coin I didn't bother mining last year.
Stackexchange user Chris Moore summarized it as
Quote
The protocol rejects blocks with a timestamp earlier than the median of the timestamps from the previous 11 blocks or later than 2 hours after the current network time. Any other timestamp is acceptable. Note that 'network time' may differ from the actual time, since the bitcoin network attempts to correct for incorrect clock settings by taking the median of the time reported by all connected peers as the network time.
I think it makes sense. After this 2 hours, of not mining, the last block known by the two clients was indeed too old to be accepted. Restarting the clients, gave them the new and actual time, after which mining could be resumed as it met the time requirements again.
I did turn of mining for ~1 hour, and both cpuminers could proceed where they left of.
To confirm this time on the network requirement, I will stop mining again for 2 hours or more (time to watch a movie ;-) or go for an evening walk) and see if the blocks will be rejected again. If they do, I'll restart one of the two clients and see what happens. I think both miners will resume operation as soon as one of the clients refreshes its timestamp on the testnet network.
No, but X11 implementation requires an external miner.
Okay. That explains why it didn't work ^^"