Fake block timestamps can cause a temporary fork?

[tonych]

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.

[DannyHamilton]

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.

The miner has to choose the block time when the start hashing the block, not after they've already found the block.  The block time is part of the header being hashed.

Since it is impossible for a miner to know how long it will take them to mine a block, it is impossible for them to accurately set a timestamp that will be exactly 2:00:00 ahead of the time that they will broadcast it.

They could potentially set a blocktime that is significantly more than 2:00:00 ahead, and then if they solve the block they can hold on to the block until the timestamp is exactly 2:00:00 in the future.  However, they then stand a significant risk that someone else will solve and broadcast a block before they get around to broadcasting their own.  That's a very expensive 25+ BTC risk for a small chance at creating an orphaned block.

[johoe]

If someone finds a block on top of the new block with the faked timestamp all miners will immediately jump to the new chain, right? Then, the worst that can happen is that someone ignores the new block and builds on the old block.  For him, there is a high risk that his block gets orphaned but the attacker also risks that his block gets orphaned.  In any case the fork will be quickly resolved.

[TimS]

The miner has to choose the block time when the start hashing the block, not after they've already found the block.  The block time is part of the header being hashed.

Since it is impossible for a miner to know how long it will take them to mine a block, it is impossible for them to accurately set a timestamp that will be exactly 2:00:00 ahead of the time that they will broadcast it.

They could potentially set a blocktime that is significantly more than 2:00:00 ahead, and then if they solve the block they can hold on to the block until the timestamp is exactly 2:00:00 in the future.  However, they then stand a significant risk that someone else will solve and broadcast a block before they get around to broadcasting their own.  That's a very expensive 25+ BTC risk for a small chance at creating an orphaned block.

You need to update the block header after every hash to change the nonce, and at least every 4.2 billion hashes when your nonce value hits its maximum. If mining software doesn't already keep the timestamp within, say, 5 seconds of the true value, it could (I'm almost certain) easily be modified to keep it at the right time without significantly affecting your hashrate.

You will, of course, broadcast it immediately upon finding it; you can guess that 50% of the network will get it in 4-5 seconds, so simply set it 2:00:05 or so ahead of your very-accurate "current time".

[Gavin Andresen]

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?

[doge94]

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?

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.

[DannyHamilton]

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?

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.

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.

[jonald_fyookball]

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.

.

The timestamping is done for difficulty adjustments, not for ordering of blocks.  The rules are there
to make sure that things don't get too far out of whack (You can't go too far backward or forward),
and yes they are specifically designed to converge the chain even if there is temporary disagreement.

[doge94]

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?

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.

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.

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.

[hhanh00]

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.

It's even harder to accomplish because the 2h are relative to the client's current time. As time passes by, a previously rejected block has a higher chance to get accepted.

[jonald_fyookball]

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.

Don't see how its any different than 2 miners finding blocks at the same time and broadcasting them to the network.  Segment "A" and Segment "B" are now forks.  If Segment A is first to find the next block, then the tip of Segment B becomes an orphan and convergence happens. 

[DeathAndTaxes]

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.

That is exactly like an orphan block.

Some of the miners will be working on one block, some on another.   A miner from one group or the other will solve the next block and when they do the network will reorg to a consensus again.   It would do absolutely nothing other than the bad timestamps block may (or may not) become orphaned.   The most direct loser would be the creator of the block as there is a good chance he will lose the mining reward.


There are attacks that can be node with timestamps but they require the victim to be (mostly) isolated from the majority of the network.   Being poorly connected and getting isolated is always an attack vector though.

[stdset]

Would a node accept once rejected block (as being e.g. 2:00:01 to the future) if another node sends that block again to our node 2 seconds later?
If yes, it looks like this situation will likely be resolved without even orphaning anything. If no, it's much graver, part of the network which initially rejected the controversial block will never accept a fork built on than block.

[hhanh00]

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

[tonych]

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

Great. That means the chances of quick recovery are high.

[tonych]

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?

No obvious benefit to the miner, just a short lived disruption of the network (I don't think it is big enough to qualify for a DoS). If successful, it would split miner resources and cause the next block to be mined at half speed.

The main point here is that relying on node current time is dangerous for consensus. Even if it doesn't cause major trouble, it complicates things. Fortunately the 2h rule is the only place in bitcoin protocol that instructs node to make a decision based on its own clock.

[jl2012]

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.

No rational miner would do this as that will increase the risk of being orphaned.

As an attack, this is also not effective as 1-block fork is already very common.

[DannyHamilton]

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

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

[jonald_fyookball]

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

No, it wouldn't 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.
 

[cr1776]

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

No, it wouldn't 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.

Both forks would be mining and the total hash rate would remain the same for the sum of the two forks.  So the next block would be mined at the same speed.

It would just be that each fork only had a 50% chance of finding the next block, so if you were looking at just one fork with half the hash rate, it might take an average of double the time for that side of the fork to find the next block.  The other side would also have the same chance.  He is neglecting that there are two forks.