This post answers some common problems people have when operating or using a mining pool. Note that those answers below are the common cause. There might be other rare causes of the problems that I’m not aware of. I would really appreciate it if you can share your situations if you think it is one of the later.

I heard that it is possible to fake the block timestamp when mining, like shifting the system clock a little bit, to gain advantage of mining rewards. Is that true?

No. No matter how the miner choose to shift the timestamp, it hurts the miner.

Timestamp, besides the not-recommended TIMESTAMP opcode in EVM, is only used for one thing – to calculate the block difficulty for the next block. Miners first finalize a block (which also set a timestamp for the block), and then start the Proof of Work algorithm ethash . When the miner is lucky and the algorithm is finished, the miner then broadcast the block.

During this process, what if the miner shift its block timestamp a little bit in the past? Well, not a lot would happen. The block would be accepted without problem, as long as the shifted timestamp is still after the previous block’s timestamp. However, in this case, the miner also cannot gain any advantage – the difficulty for the next block would be raised higher than normal, thus makes it harder than normal to mine the next block. So a rational miner will not do that.

What if the miner shift its block timestamp a little bit to the future? This is basically gambling for the miner because all current Ethereum full nodes also have another consensus rule – that if a block’s timestamp is in the future relative to the system clock, then it is rejected. You can test this by slightly shift your system clock by one minute to the past. Now run your Parity or Geth client, you will see that the node will start to reject valid network blocks, because it thinks that they’re mined “in the future” and thus breaks the consensus rules.

So there is indeed a really small window, between a block is finalized, and the block is mined, that the miner can choose to shift its block timestamp. First, this is really tricky because for a miner, if it has already mined the block but the actual world clock has not yet passed the set block timestamp, it would need to withheld the block until then, and during this time, cannot mine new blocks. This hurts the profit of the miner. What if the miner is smart enough to always set the timestamp before when the block is mined? In this case, it is equivalent to the miner withheld its hashrate – I claim that I mined this block using this amount of time, but the actual time I spent is shorter. However, a side effect of a miner doing this is that its block difficulty would be lower. In chain selection, we always choose the chain with the most accumulated difficulty (called “total difficulty”). By withhelding hashrates, the miner risks losing the competition and its block risks to get orphaned.

In conclusion, both shifting the block timestamp to the future, and shifting the block timestamp to the past hurt the miner, rather than helping them to gain rewards.