Topic: Fake block timestamps can cause a temporary fork? (Read 2371 times)

No, it really wouldn't, any more than a business-as-usual temporary blockchain race/fork creates confusion or breaks applications. Like the one-block fork we had today.

It would create a temporary fork and perhaps some confusion. Maybe even break some badly coded bitcoin applications if they do not handle forks well.

Why would a miner want only half the network to build on their block?

That makes no sense... what is the +2hr timestamp miner trying to accomplish?

Every block includes a timestamp as set by the miner who mined the block. There is a rule that other nodes reject the block if its timestamp is more than 2 hours in the future. It is a hard limit: if the timestamp is 2:00:01 in the future relative to node time, the node rejects it; if it's only 1:59:59 in the future, the node accepts it.

What happens if a miner finds a block and sets its timestamp exactly 2 hours in the future relative to some accurate time source? Since the clocks of all other nodes are never perfectly synchronized and distributed somewhere around the true time, I would expect that approximately half of the nodes (whose clock is slightly ahead of the true time) accept the block, while the other half will reject and forget it. Half of the miners will accept the block and start building a new block on top of it (with half of the original hash power), the other half will continue working on the previous block. We've got a blockchain fork caused by misbehavior of just one node. One of the two forks will eventually win but, before that, transaction confirmations might be delayed. Did I get anything wrong?

I think when designing a distributed consensus system, such as Bitcoin, one should be cautious about making a decision based on node time. Node time is different at different nodes and this a source of disagreement that potentially destroys consensus. Hopefully just temporarily.

I like the dice example, there is one small difference though.
If the controversial block was block number 1001 then the miners who initially rejected it (segment B) will continue working on another version of block 1001 while the miners who accepted it will switch to block 1002. That means, for segment B to win, it'll have to produce 2 blocks (1001 and 1002) faster than equally powerful segment A produces one block 1002. This probability is low, and segment B is probably wasting its resources.

There is no long term damage anyway.

I think he means if a 1 block fork was in fact generated
and split the network 50/50...

Then in that case, I think it would cause the next block to be mined at half speed.

I think he means if a 1 block fork was in fact generated
and split the network 50/50... Then in that case, I think
it would cause the next block to be mined at half speed.
 

No, it wouldn't cause the next block to be mined at half speed.

- snip -
If successful, it would split miner resources and cause the next block to be mined at half speed.
- snip -

Every block includes a timestamp as set by the miner who mined the block. There is a rule that other nodes reject the block if its timestamp is more than 2 hours in the future. It is a hard limit: if the timestamp is 2:00:01 in the future relative to node time, the node rejects it; if it's only 1:59:59 in the future, the node accepts it.

What happens if a miner finds a block and sets its timestamp exactly 2 hours in the future relative to some accurate time source? Since the clocks of all other nodes are never perfectly synchronized and distributed somewhere around the true time, I would expect that approximately half of the nodes (whose clock is slightly ahead of the true time) accept the block, while the other half will reject and forget it. Half of the miners will accept the block and start building a new block on top of it (with half of the original hash power), the other half will continue working on the previous block. We've got a blockchain fork caused by misbehavior of just one node. One of the two forks will eventually win but, before that, transaction confirmations might be delayed. Did I get anything wrong?

I think when designing a distributed consensus system, such as Bitcoin, one should be cautious about making a decision based on node time. Node time is different at different nodes and this a source of disagreement that potentially destroys consensus. Hopefully just temporarily.

Why would a miner want only half the network to build on their block?

That makes no sense... what is the +2hr timestamp miner trying to accomplish?

Yes, it's done in CheckBlockHeader called from CheckBlock preventing the block from being cached.

Orphan blocks are a different case than an 2hr shift. When dealing with bitcoin edge cases are very common and sometimes not very well handled. What if half of the miners rejected the block and half accepted the block due to different local times? Then you would have different parts of the network contributing to different forks which is not as cut and dried as an orphan block. It would not be impossible, though highly unlikely.

Orphan blocks are a different case than an 2hr shift. When dealing with bitcoin edge cases are very common and sometimes not very well handled. What if half of the miners rejected the block and half accepted the block due to different local times? Then you would have different parts of the network contributing to different forks which is not as cut and dried as an orphan block. It would not be impossible, though highly unlikely.

Orphan blocks are a different case than an 2hr shift. When dealing with bitcoin edge cases are very common and sometimes not very well handled. What if half of the miners rejected the block and half accepted the block due to different local times? Then you would have different parts of the network contributing to different forks which is not as cut and dried as an orphan block. It would not be impossible, though highly unlikely.

Temporary forks happen every day (they are often called "orphan" blocks).  Every time two miners (or pools) solve a block at close to the same time, some of the network hears about one block first, while some of the network hears about the other block first.  Bitcoin is designed to work this way, and to adapt properly to the longest fork once another block is found.

Any "badly coded bitcoin applications" are already broken if they don't handle this daily occurrence properly.