Blockchain Tech

[d57heinz]

Ive noticed something very odd about the blockchain recently.. and it has involved discus fish both times. I cant remember the previous blocks this happened on.  Looking at block https://blockchain.info/block-index/441880/00000000000000000eef6ea3ee2d6bb263605f916df16fb4b36a1518df593428 and block https://blockchain.info/block-index/441881/00000000000000003ebb1d77027d7b18bc9fb033f29aa552d6cf7ee0a8cf692b  im trying to figure out how 308476 came before 308475.  in looking at the times 76 was 35 minutes ago and 75 was 29 minutes ago how can 76 be found 5 minutes before 75? Im relatively new to crypto so a little understanding how this can happen please...Thanks

d57heinz

[TheRealSteve]

The timestamps on blocks are set by the miners - as long as they stay within a 2 hour threshold (I think it was 2 hours), the network doesn't worry about it.  The received time depends on when the node (in this case, one of blockchain's nodes) gets it.  However, if blockchain.info has apparently bad data on that timestamp, it will default to the timestamp in the block (you'll notice they're equal for both blocks you linked to).

That said... it looks like after Block 290042 the received timestamp and block timestamp are all equal (somebody working with the API could do a more thorough check).  Here's block 290042 which shows the time stamp difference between received and block that would be more natural:
https://blockchain.info/block/0000000000000000def952fd91504f3c2da9ff129d3a0a004a09100db640fd35

So it's possible that field is entirely ignorable for blockchain.info now, which just reduces things to "the miners set the timestamps" and so a later block having an earlier timestamp is 'normal'.

( Even though miners would do well to properly sync up, and also not set timestamp incorrectly on purpose.. you know who you are )

[d57heinz]

The timestamps on blocks are set by the miners - as long as they stay within a 2 hour threshold (I think it was 2 hours), the network doesn't worry about it.  The received time depends on when the node (in this case, one of blockchain's nodes) gets it.  However, if blockchain.info has apparently bad data on that timestamp, it will default to the timestamp in the block (you'll notice they're equal for both blocks you linked to).

That said... it looks like after Block 290042 the received timestamp and block timestamp are all equal (somebody working with the API could do a more thorough check).  Here's block 290042 which shows the time stamp difference between received and block that would be more natural:
https://blockchain.info/block/0000000000000000def952fd91504f3c2da9ff129d3a0a004a09100db640fd35

So it's possible that field is entirely ignorable for blockchain.info now, which just reduces things to "the miners set the timestamps" and so a later block having an earlier timestamp is 'normal'.

( Even though miners would do well to properly sync up, and also not set timestamp incorrectly on purpose.. you know who you are )

Thanks for clearing that up for me.. I thought after posting it could have been a db error but wasn't sure.. Appreciate the clarification..