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
106
107
108
109
110
111
|
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 <SRS0=smIHeWRv=36=jerviss.org=kjj@jerviss.org>)
id 1R3Vn3-0004kH-7r for bitcoin-development@lists.sourceforge.net;
Tue, 13 Sep 2011 16:24:53 +0000
X-ACL-Warn:
Received: from serv.jerviss.org ([12.47.47.47] helo=inana.jerviss.org)
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1R3Vn2-0007tG-AM
for bitcoin-development@lists.sourceforge.net;
Tue, 13 Sep 2011 16:24:53 +0000
Received: from [156.99.25.142] ([156.99.25.142])
(username: kjj authenticated by PLAIN symmetric_key_bits=0)
by inana.jerviss.org (8.13.6/8.12.11) with ESMTP id p8DGOZIC008337
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Tue, 13 Sep 2011 11:24:40 -0500
Message-ID: <4E6F83C3.9020108@jerviss.org>
Date: Tue, 13 Sep 2011 11:24:35 -0500
From: kjj <kjj@jerviss.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
rv:6.0.2) Gecko/20110902 SeaMonkey/2.3.3
MIME-Version: 1.0
To: Gavin Andresen <gavinandresen@gmail.com>
References: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
In-Reply-To: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (inana.jerviss.org: 156.99.25.142 is authenticated by a
trusted mechanism)
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1R3Vn2-0007tG-AM
Cc: 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: Tue, 13 Sep 2011 16:24:53 -0000
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.
|
