1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sipa@ulyssis.org>) id 1RNQiv-0004fK-8T
for bitcoin-development@lists.sourceforge.net;
Mon, 07 Nov 2011 15:02:57 +0000
X-ACL-Warn:
Received: from rhcavuit02.kulnet.kuleuven.be ([134.58.240.130]
helo=cavuit02.kulnet.kuleuven.be)
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RNQiq-00064b-Ks for bitcoin-development@lists.sourceforge.net;
Mon, 07 Nov 2011 15:02:57 +0000
X-KULeuven-Envelope-From: sipa@ulyssis.org
X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5,
autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00,
FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20)
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 3C4EE1280A0.A79A5
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be
[134.58.240.75])
by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 3C4EE1280A0;
Mon, 7 Nov 2011 16:02:43 +0100 (CET)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps02.kuleuven.be (Postfix) with ESMTP id 0F50CF3863;
Mon, 7 Nov 2011 16:02:43 +0100 (CET)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id 3BBC310052;
Mon, 7 Nov 2011 16:03:10 +0100 (CET)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id 512C187C1B1; Mon, 7 Nov 2011 16:02:43 +0100 (CET)
Date: Mon, 7 Nov 2011 16:02:43 +0100
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20111107150240.GA26096@ulyssis.org>
References: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
X-Headers-End: 1RNQiq-00064b-Ks
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2011 15:02:57 -0000
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
|
