Block in future timestamp ?

[btc_enigma]

Today I found a block having timestamp which is > current time . Found this on my bitcoin node

Just to be sure I googled this on blockchain.info and found similar result:



Blockr had similar timestamp in the future ... but tradeblock was showing a past timestamp as expected

Wondering if somone could throw some light on this, is this expected ?

[monsterer]

Timestamps are unreliable in a peer to peer environment. The only true 'time stamping' is POW.

[btc_enigma]

Timestamps are unreliable in a peer to peer environment. The only true 'time stamping' is POW.

So nodes will accept blocks with timestamp > current time ?

[monsterer]

Timestamps are unreliable in a peer to peer environment. The only true 'time stamping' is POW.

So nodes will accept blocks with timestamp > current time ?

There is a wide bounds for acceptability, I can't remember the exact bounding they use.

[achow101]

Timestamps are unreliable in a peer to peer environment. The only true 'time stamping' is POW.

So nodes will accept blocks with timestamp > current time ?

There is a wide bounds for acceptability, I can't remember the exact bounding they use.

I think the bounds are 120 minutes either way of the node's time.

[btc_enigma]

Timestamps are unreliable in a peer to peer environment. The only true 'time stamping' is POW.

So nodes will accept blocks with timestamp > current time ?

There is a wide bounds for acceptability, I can't remember the exact bounding they use.

I think the bounds are 120 minutes either way of the node's time.

What is rational behind this design, I understand 1 min or so , for time lags on node . If block timestamp is so unreliable, what is the point of having it in the block header. This could lead to cases where timestamp of block n < timestamp of block n-1

[amaclin]

bc.i has a bug

this site always shows the same timestamp for Block Timestamp and Received Time

[DannyHamilton]

What is rational behind this design,

The only thing the timestamp is intended to be used for is calculating the new proof-of-work difficulty every 2016 blocks.  A variation in timestamps of 120 minutes or so isn't a problem for that use case, and it means that the decentralized peer-to-peer system doesn't need a centralized source of time that everyone can agree on.

This could lead to cases where timestamp of block n < timestamp of block n-1

Yes.  It happens all the time.

[btc_enigma]

The only thing the timestamp is intended to be used for is calculating the new proof-of-work difficulty every 2016 blocks.  A variation in timestamps of 120 minutes or so isn't a problem for that use case, and it means that the decentralized peer-to-peer system doesn't need a centralized source of time that everyone can agree on.

Thanks. Make sense !

[spin]

Yes.  It happens all the time.

Pardon the pun?