public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: kjj <kjj@jerviss.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues
Date: Tue, 13 Sep 2011 11:24:35 -0500	[thread overview]
Message-ID: <4E6F83C3.9020108@jerviss.org> (raw)
In-Reply-To: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>

Gavin Andresen wrote:
> Background:
>
> Timejacking:
>    http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html
>
> And a recent related exploit launched against the low-difficulty
> alternative chains:
>    https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
>
>
> Seems to me there are two fundamental problems:
>
> 1) Bitcoin should be overlapping the ranges of block timestamps that
> it uses to calculate difficulty adjustments.
>
> 2) Bitcoin's "what time is it" code is kind of a hack.
>
>
> Fixing (1) would mean a potential block-chain split; before
> considering doing that I'd like to consider second-best solutions.
>
> Fixing (2) is easier; incorporating a ntp library and/or simply
> removing the bitcoin mining code from the client but requiring pools
> and miners to have accurate-to-within-a-minute system clocks (or their
> blocks will be "discouraged") seems reasonable to me. If you want to
> produce blocks that the rest of the network will accept, run ntp on
> your system.
>
> I THINK that fixing (2) will make (1) a non-issue-- if miners can't
> mess around with block times very much then it will be very difficult
> for them to manipulate the difficulty for their benefit.
>
The first thing I always do when I grab the source for my colo server is 
patch util.cpp so that GetAdjustedTime() returns GetTime() with no 
adjustment.  But I'm the kind of guy that buys special GPS receivers 
because stratum 2 isn't low enough and occasionally checks ebay for 
caesium fountains.

NTP has been around for long enough now that there is no reason for the 
client to screw with the clock.  If the client sees different times on 
the network, it should issue a warning, and if it is off too far, it 
should give an error and fail to run (and/or peers should reject it).

But that doesn't solve the whole problem, because the block timestamp 
checking is based on the assumption that the node is looking at the 
bitcoin clock rather than the, ahem, real clock.  If we change the idea 
of network time to NTP, we will then need to write (and test!) new block 
timestamp rules to account for the new assumptions.

I'm not sure that just fixing item 2 is going to stop the attacks found 
by ArtForz, et al.  Some of the attacks Art pointed out are particularly 
bad because they change the incentive structure of the system, at least 
in the short term.  We need to flip that back around ASAP.

Also, this is going to cause problems for at least one pool operator.



  parent reply	other threads:[~2011-09-13 16:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-13 15:06 [Bitcoin-development] Difficulty adjustment / time issues Gavin Andresen
2011-09-13 15:15 ` Vladimir Marchenko
2011-09-13 15:54 ` John Smith
2011-09-13 16:24 ` kjj [this message]
2011-09-14 14:45   ` Gavin Andresen
2011-09-14 15:43     ` Luke-Jr
2011-09-14 16:06       ` Christian Decker
2011-09-14 19:52     ` Aidan Thornton
2011-09-14 20:09       ` Gregory Maxwell
2011-09-14 20:28         ` Gavin Andresen
2011-09-14 21:36           ` Alex Waters
2011-09-14 21:51             ` Gregory Maxwell
2011-09-14 22:07               ` theymos
2011-09-14 23:01         ` Luke-Jr
2011-09-13 16:48 ` Luke-Jr
2011-09-14 21:45 ` theymos
2011-11-07 15:02 ` Pieter Wuille
2011-11-07 15:27   ` Luke-Jr
2011-11-07 15:43     ` Pieter Wuille

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E6F83C3.9020108@jerviss.org \
    --to=kjj@jerviss.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gavinandresen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox