Bitcoin Forum
October 03, 2024, 02:27:01 AM *
News: Latest Bitcoin Core release: 27.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Some blocks have earlier block times than their predecessing block, how/why?  (Read 889 times)
Kazimir (OP)
Legendary
*
Offline Offline

Activity: 1176
Merit: 1011



View Profile
August 09, 2015, 07:34:27 AM
Merited by ABCbits (1)
 #1

I noticed that quite frequently a block is mined at an earlier time than its predecessor. At least according to its timestamp, which is generated by the server that mined the block, and obviously they can have some difference. But the differences are quite large sometimes (over 10 minutes).

For example:

Block 368511 was mined at 2015-08-05 15:49:19, and the next block was mined at 2015-08-05 15:37:55 (almost 12 minutes earlier).

Or block 367387 was mined at July 28th 2015, 22:36:45, and the next block was mined July 28th 2015, 22:25:56 (again, almost 12 minutes earlier).

I'm using different block explorers to indicate it's not a bug in a particular block explorer, these times are the same everywhere.

What's up with that? Is there a trustworthy method of restoring a block's actual, correct time of mining?

In theory, there's no difference between theory and practice. In practice, there is.
Insert coin(s): 1KazimirL9MNcnFnoosGrEkmMsbYLxPPob
heretolearn
Full Member
***
Offline Offline

Activity: 128
Merit: 101



View Profile
August 09, 2015, 07:56:55 AM
Merited by ABCbits (1)
 #2

There is no central authority to keep track of time. The block is mined by computers running on different timezones worldwide. For a block to be included it must pass some basic sanity tests - the block time is not earlier than the median of the last 11 blocks. So as long as thats fine, its included.
shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1498
Merit: 1530


No I dont escrow anymore.


View Profile
August 09, 2015, 08:42:50 AM
Merited by ABCbits (1)
 #3

-snip-
What's up with that? Is there a trustworthy method of restoring a block's actual, correct time of mining?

No, because of what heretolearn said and the fact that the timestamp influences the blocks hash miners tend to manipulate the timestamp for mining purposes. The exact time for a block is not that crucial to the network.

Im not really here, its just your imagination.
Kazimir (OP)
Legendary
*
Offline Offline

Activity: 1176
Merit: 1011



View Profile
August 09, 2015, 09:20:36 AM
Last edit: August 09, 2015, 09:31:17 AM by Kazimir
 #4

Then how do we agree on the next difficulty / retarget ?

Do we take the block time for that, even though we know they're not accurate? (I can see how that works, just wondering)

*edit* now that I think of it, I can see how that works with Bitcoin, taking the average over the past 2016 blocks, but how would that work with altcoins that retarget much faster, or even after every single block? (albeit a gradual retarget, e.g. gravity well formulas)

In theory, there's no difference between theory and practice. In practice, there is.
Insert coin(s): 1KazimirL9MNcnFnoosGrEkmMsbYLxPPob
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4242
Merit: 8702



View Profile WWW
August 11, 2015, 11:20:56 PM
Merited by ABCbits (1)
 #5

Who says what the altcoins do actually works-- many have just had spontanious failures due to ill advised changes like twiddling how retargeting works... and there is no reason to expect that most have ever been analyized from an adversarial perspective (much less  actually attacked). ... but thats a question for another subforum.

As you note, it works fine in Bitcoin as is... and, in fact, requiring the time to be monotonic would open up new attacks.  If you want a monotonic time out of bitcoin you can extract one by simply running a rolling maximum over the timestamps, forcing miners to conceal more information won't help anything.
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1007


View Profile
August 12, 2015, 09:14:20 AM
 #6

Having timestamps in blocks is a regrettable consequence of the requirement to adjust for difficulty.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!