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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <theymos@mm.st>) id 1R3xH1-0000n7-JT
for bitcoin-development@lists.sourceforge.net;
Wed, 14 Sep 2011 21:45:39 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of mm.st
designates 66.111.4.27 as permitted sender)
client-ip=66.111.4.27; envelope-from=theymos@mm.st;
helo=out3.smtp.messagingengine.com;
Received: from out3.smtp.messagingengine.com ([66.111.4.27])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1R3xH0-0005CT-Lv
for bitcoin-development@lists.sourceforge.net;
Wed, 14 Sep 2011 21:45:39 +0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 42BDC2B23E
for <bitcoin-development@lists.sourceforge.net>;
Wed, 14 Sep 2011 17:45:33 -0400 (EDT)
Received: from web3.nyi.mail.srv.osa ([10.202.2.213])
by compute4.internal (MEProxy); Wed, 14 Sep 2011 17:45:33 -0400
Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99)
id 23C3DA805A1; Wed, 14 Sep 2011 17:45:33 -0400 (EDT)
Message-Id: <1316036733.29037.140258141218893@webmail.messagingengine.com>
X-Sasl-Enc: XFLpUFYyCQiIrzt1OWdr95USHSA4e5V5R+SD39uE721d 1316036733
From: "theymos" <theymos@mm.st>
To: bitcoin-development@lists.sourceforge.net
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
References: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
Date: Wed, 14 Sep 2011 16:45:33 -0500
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.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(theymos[at]mm.st)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service
X-Headers-End: 1R3xH0-0005CT-Lv
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: Wed, 14 Sep 2011 21:45:39 -0000
A better retarget strategy might be to use the real average time
between all of the blocks in the interval so that no blocks are
treated specially in the calculation. I agree that this is not
important enough to fork the chain over, though. An attacker would
have to maintain control for a *very* long time because of Bitcoin's
long retarget interval. (Maybe this kind of thing is why the retarget
interval is so long?)
I don't like requiring block times to be within minutes of reality. It
would be fine if only miners had to keep accurate time, but clients will
also need to have good time in order to see if a block will be
discouraged. A discouraged block should not count toward confirmations.
If relays will also discourage blocks, then they'll need accurate
time as well.
The network should not be allowed to adjust your time by more than 40
minutes to prevent the timejacking attack, but I don't see a problem
with the other time rules. Time is only used for retargets and LockTime,
so it only needs to be generally accurate.
|
