Bitcoin Forum
December 04, 2016, 04:10:16 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Is something wrong with the blockchain  (Read 1617 times)
Okama
Newbie
*
Offline Offline

Activity: 23


View Profile
September 15, 2011, 10:24:51 AM
 #1

145420
Code:
http://blockexplorer.com/block/00000000000002cd0003629d5e515222261fd290af22012c9d52375c7778f5ea

[b]Time?: 2011-09-15 06:55:09[/b]

145419
Code:
http://blockexplorer.com/block/0000000000000078ce8d6a3cacbf388d01102abed511dd8d798f75878c21a273

[b]Time?: 2011-09-15 07:16:37[/b]

Something wrong?
1480824616
Hero Member
*
Offline Offline

Posts: 1480824616

View Profile Personal Message (Offline)

Ignore
1480824616
Reply with quote  #2

1480824616
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
wareen
Millionaire
Hero Member
*****
Offline Offline

Activity: 742

bitcoin-austria.at


View Profile
September 15, 2011, 10:48:37 AM
 #2

Not really, block timestamps are taken from the computer that solves the block and have no special meaning within Bitcoin. The nodes in the Bitcoin network accept blocks which are at most 2 hours off their own clock, so it is perfectly possible to see the next block having a timestamp before the last block.

There's also talk about some miners (pools) deliberately offsetting their clocks.
JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
September 15, 2011, 11:10:54 AM
 #3

If the protocol demanded strictly-increasing timestamps, what should you do if a block shows up whose timestamp is one minute ahead of what you think the time is? Should you stop mining for a minute? Should you mine blocks with a timestamp you believe is wrong?

Because it is important that the network as a whole agree on whether a block is valid, it doesn't make sense to insist on monotonically increasing timestamps.

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
aq
Full Member
***
Offline Offline

Activity: 238


View Profile
September 15, 2011, 12:14:16 PM
 #4

If the protocol demanded strictly-increasing timestamps, what should you do if a block shows up whose timestamp is one minute ahead of what you think the time is? Should you stop mining for a minute? Should you mine blocks with a timestamp you believe is wrong?

Because it is important that the network as a whole agree on whether a block is valid, it doesn't make sense to insist on monotonically increasing timestamps.

There is a hardcoded limit implemented right now, 2 hours. So what would be the difference between 2 hours and 1 minute? In both cases it is a clear cut. Either the block is declared valid or not valid. So today the current question is "what should you do if a block shows up whose timestamp is 2 hours and one minute ahead of what you think the time is? Should you stop mining for a minute? Should you mine blocks with a timestamp you believe is wrong?" Looking at the current code, it is clear that this block would just be invalid.
Now even if this would be 20 years ago, I would say 2 hours is way too much. I think it would take years for an average real time clock to accumulate a clock drift of 2 hours. So I guess, the only reason we still have 2 hours is that some pool operator(s?) like to play with the timestamps - I highly doubt that anyone else mining is not using the correct time:

Well, there is some bleeding edge new technology called NTP. Oops, we have this since well before '85. http://en.wikipedia.org/wiki/Network_Time_Protocol  But of course using NTP would force us to have some online connection (aka internet) maybe once a day to correct the time drift of the built-in real time clock. Wait, Bitcoin needs an online connection anyway, so the legitimate is why does Bitcoin not use NTP?
aq
Full Member
***
Offline Offline

Activity: 238


View Profile
September 15, 2011, 12:38:51 PM
 #5

Trivial time range shrinking from starting October 2011 (2 hours) and ending March 2012 (1 minute).

Current code:
Code:

    // Check timestamp
    if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
        return error("CheckBlock() : block timestamp too far in the future");

New code:
Code:
    // Check timestamp
    int64 range = 1333000000 - GetBlockTime();
    if (range < 0)
        range = 0;
    range /= 2048;
    if (range > 2 * 60 * 60 - 60)
        range = 2 * 60 * 60 - 60;
    range += 60;
    if (GetBlockTime() > GetAdjustedTime() + range)
        return error("CheckBlock() : block timestamp too far in the future");

Code is just typed in, untested. So it probably contains bugs Wink
Ayo_4_Yayo
Jr. Member
*
Offline Offline

Activity: 42



View Profile
September 15, 2011, 03:28:54 PM
 #6

It doesn't look right. It requires further investigation. Anyone willing!?!?!?!
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
September 15, 2011, 06:43:52 PM
 #7

There was some discussion of this issue on the mailing list recently. It's worth review if you're seriously investigating this. The upshot is that throwing this sort of change in could fork the block chain or have other unexpected effects.

http://sourceforge.net/mailarchive/message.php?msg_id=28082081

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
September 16, 2011, 12:12:47 AM
 #8

There is a hardcoded limit implemented right now, 2 hours. So what would be the difference between 2 hours and 1 minute?
The difference would be that the probability of inadvertently entering a situation where large parts of the network disagree over a block's validity would be much, much lower.

Quote
Well, there is some bleeding edge new technology called NTP. Oops, we have this since well before '85. http://en.wikipedia.org/wiki/Network_Time_Protocol  But of course using NTP would force us to have some online connection (aka internet) maybe once a day to correct the time drift of the built-in real time clock. Wait, Bitcoin needs an online connection anyway, so the legitimate is why does Bitcoin not use NTP?
Nothing prevents people from using NTP to mine blocks with accurate timestamps. If the question is why Bitcoin doesn't force people to provide more accurate timestamps it's because there's no technical requirement for them and it increases the risk of inadvertently entering a situation where large parts of the network disagree over a block's validity.

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
phillipsjk
Legendary
*
Offline Offline

Activity: 1008

Let the chips fall where they may.


View Profile WWW
September 16, 2011, 04:05:58 AM
 #9

As far as I know, some popular OS's still use local time for their hardware clock instead of UTC.

This is a problem during transistions between daylight savings time and standard time. Normally, the NTP server is not completely trusted and large, sudden shifts in time are avoided. If you are dual-booting with you hardware clock set to local time, you OS has no way of knowing if the other has changed the clock or not (unless you take the time to disable automatic time changes).

TL;DR: unless your hardware clock is set to UTC, it is entirely reasonable to expect your clock to be off by up to an hour about twice a year. Even if you are using NTP.

James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
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!