Block and coinstake timestamp rules

From Bitcoin wiki page:

Each block contains a Unix time timestamp. In addition to serving as a source of variation for the block hash, they also make it more difficult for an adversary to manipulate the block chain.

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. “Network-adjusted time” is the median of the timestamps returned by all nodes connected to you.

Whenever a node connects to another node, it gets a UTC timestamp from it, and stores its offset from node-local UTC. The network-adjusted time is then the node-local UTC plus the median offset from all connected nodes. Network time is never adjusted more than 70 minutes from local system time, however.

Bitcoin uses an unsigned integer for the timestamp, so the year 2038 problem is delayed for another 68 years.

Reddcoin follows the same timestamp rules for blocks. The lower bound of the timestamp of a new block is enforced at this line of code. The upper bound is enforced at here.

Coinstake transactions, which technically represent blocks, should follow the same timestamp rules. When a staker creates a new coinstake, its timestamp rule is enforced at this line of code.

The bug that caused the staking to be stuck is due to function PastDrift incorrectly defined as 10min. Let’s assume the current wall clock time is T and the tip of the blockchain somehow has a timestamp of T+1h (either by accident or intention). At T+1min a new coinstake is created with a timestamp of T+1min. Unfortunately it’s rejected because its timestamp is earlier than (T+1h-10min), which means no one can create a new coinstake transaction until around 50min later.

Thanks for the update and clear explanation. Bonus points for references to the code :stuck_out_tongue:

Thanks for taking the time to explain this. I love reading info like this even if I may not always understand 100% of it.

1 Like