public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues
Date: Mon, 7 Nov 2011 16:02:43 +0100	[thread overview]
Message-ID: <20111107150240.GA26096@ulyssis.org> (raw)
In-Reply-To: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>

On Tue, Sep 13, 2011 at 11:06:37AM -0400, 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

Here is an idea for an alternative (simple but hacky) solution:
* Keep all network rules as they are now.
* The timestamp value of mutliple-of-2016-blocks is set equal to
  the highest timestamp that occurred in the previous 11 blocks,
  instead of the current time. This will always obey the previous
  rules (it's always at least the median of the past 11 blocks,
  and never more in the future than them).

Initially, roll out software that only uses this new rule for
block creation, but doesn't enforce it. When enough miners have
upgraded, choose a point in the future where it becomes mandatory
(causing a block chain split only for those creating blocks using
old software).

If i understand the problem correctly, this will prevent an attacker
from introducing a time lapse in between the 2015-block windows.
One problem i do see, is that it prevents X-Roll-Time for miners.
Maybe a short interval (1 minute? 10 minutes?) instead of a fixed
value could be allowed for the multiple-of-2016 blocks.

Comments?

-- 
Pieter




  parent reply	other threads:[~2011-11-07 15:02 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
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 [this message]
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=20111107150240.GA26096@ulyssis.org \
    --to=pieter.wuille@gmail.com \
    --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