Bitcoin Forum
October 22, 2017, 02:09:06 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Newer block has older age  (Read 892 times)
duke1839
Full Member
***
Offline Offline

Activity: 141


View Profile
March 18, 2015, 06:40:59 AM
 #1

I noticed that block number 348096 had an older age by about half a minute from the previous block 348095.  How can this happen or is this just an error on the blockchain site?

1839REgeNTM2b84byywinp3BjtWdEqw27x
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
MegaFall
Jr. Member
*
Offline Offline

Activity: 56


View Profile
March 18, 2015, 06:51:46 AM
 #2

Just a guess, but there's probably a small amount leniency in the system to compensate for blocks that are found within a minute or two of each other; a latency compensation thing. They were found like 40 seconds apart. 
matt4054
Legendary
*
Offline Offline

Activity: 1372


BitcoinQueue.com


View Profile WWW
March 18, 2015, 06:56:10 AM
 #3

Block timestamps are set by the block miner/pool. Since Bitcoin is decentralized, there is no absolute time reference within the network (and there shouldn't be). There will always be clock variations between nodes. The blockchain is all about consensus, and the protocol has a tolerance for next block candidates timestamps: they can be slightly in the future, and even slightly in the past, compared to your local clock and the timestamps of previous blocks already in the chain.

In other words, the timestamp is not a strictly increasing sequence, while the block height (of the main chain) is.
duke1839
Full Member
***
Offline Offline

Activity: 141


View Profile
March 18, 2015, 07:31:30 AM
 #4

Block timestamps are set by the block miner/pool. Since Bitcoin is decentralized, there is no absolute time reference within the network (and there shouldn't be). There will always be clock variations between nodes. The blockchain is all about consensus, and the protocol has a tolerance for next block candidates timestamps: they can be slightly in the future, and even slightly in the past, compared to your local clock and the timestamps of previous blocks already in the chain.

In other words, the timestamp is not a strictly increasing sequence, while the block height (of the main chain) is.

Thank you, that makes perfect sense.

1839REgeNTM2b84byywinp3BjtWdEqw27x
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
March 19, 2015, 04:46:55 PM
 #5

Just by memory, I think that the new block's timestamp must be:

1. Later than the mean (median?) of the last 11 blocks.
 AND
2. Not more than 2 hours into the future, based on the local node's notion of time1.

Requirement 1 means that the clock must move forward, overall.

Requirement 2 is soft.   A block rejected by it will be accepted eventually, assuming that a better one doesn't show up first.  Globally, it limits a miner's ability to mess with the clock.  Without it, a group of miners could agree to run the clock fast, reducing the apparent work, artificially lowering the difficulty, increasing their profits.2

1.  Note that this is node time, which is not necessarily the same as the node's OS time or hardware RTC time.

2.  If you think that this causes a weakness in the system, work through the implications carefully.  The distribution of work between the normal and fast chains is important.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Cryddit
Legendary
*
Offline Offline

Activity: 840


View Profile
March 20, 2015, 09:02:18 PM
 #6


I've thought about this...  and not really reached a significant conclusion.

I worry when I get silly time stamps.  It could mean somebody is trying to so some kind of timing attack.  I mean, it doesn't normally mean that, and I'm not aware of any history of such attacks that have been made specifically against Bitcoin, but ....  well, I worry about stuff.

It would make sense, sort of, if nodes did not relay blocks whose timestamp is before the node's local time.  But if that were the case the network would sprout a new attack surface where nodes whose clocks were a minute late or a minute early could be forked off from the rest of the network, possibly for sequences several more blocks deep. 

So tolerating the occasional silly timestamp seems like the lesser evil.

 

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!