Topic: Network time (Read 1236 times)

How does that work?  Nodes forward blocks as they add them to their chain.  The 1 honest node won't forward the block a 2nd time, since it will only forward the block when it added it to its own block chain.

Is it that when it gets the next block, it will ask for the previous one?

No, as time passes, that block's timestamp will move closer and closer to the node's apparent time, and will eventually be inside the window.  At that point, the node will catch up on all missing blocks (unless the attacker has enough hashing power to make ALL blocks be 90 minutes in the future).

AFAIK the only place where the time matters is when accepting a new block - it's time stamp must be not father in the future than now +2 hours.
So the precision is not so important. In fact I believe if there was no network time concept (every node would just use its own time), bitcoin would have worked equally well.

The current system for checking time is to use the median of connected nodes.  The node says what its timestamp is and the system compares that to the local system time.

When a node connects, a map entry is created mapping the node's IP address to the time offset.

If the map has an odd number, at least 5, of values, the median is calculated in order to give a time offset estimate.

This means that if a node is connected to 1 honest node and 7 dishonest nodes, the dishonest nodes can control the time offset.

If the difference is more than 70 minutes from system time, an error is displayed and the node reverts to the system clock.

The "timejack" attack is to cause the node's clock to be set 60 minutes behind realtime.

Once that is achieved, the dishonest miners mine a block with a timestamp 1hr30 into the future.

Once they hit that block, it is broadcast throughout the network.  There is a check to make sure the blocks are no more than 2 hours into the future.

The compromised node will immediately discard the block since it is 2hr30 into the future.  This means that the node will ignore all future blocks, since it is missing one link in the chain.

A simple solution is to check the POW for blocks that have timestamps less than 24 hours into the future.  They could be stored for checking later.  Effectively, they would be treated like orphan blocks.

However, they would leave the orphan area once their timestamp is less than 2 hours in the future.

Another option would be the "child pays for parent" system.  If a block is received that builds on a block that is in the holding area, but is less than 2 hours into the future itself, the block is processed anyway.

This is another example of where block headers broadcasting would help.

System time could be estimated by using the offset of when block headers are received.  For example, the node could use the median offset for the last 11 block headers as its time estimate.

When a block header is received and it is within 2 hours of system time, the offset is calculated relative to current system time.  The median offset for the last 11 blocks could be used as one of the time estimates.

Even if only 1 of the eight peers are honest, this estimate would be accurate.