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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1R3vla-0007le-Gu
for bitcoin-development@lists.sourceforge.net;
Wed, 14 Sep 2011 20:09:06 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.182 as permitted sender)
client-ip=209.85.216.182; envelope-from=gmaxwell@gmail.com;
helo=mail-qy0-f182.google.com;
Received: from mail-qy0-f182.google.com ([209.85.216.182])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1R3vlZ-0007EZ-Rf
for bitcoin-development@lists.sourceforge.net;
Wed, 14 Sep 2011 20:09:06 +0000
Received: by qyk4 with SMTP id 4so2289996qyk.13
for <bitcoin-development@lists.sourceforge.net>;
Wed, 14 Sep 2011 13:09:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.226.209 with SMTP id ix17mr234753qcb.147.1316030940412;
Wed, 14 Sep 2011 13:09:00 -0700 (PDT)
Received: by 10.229.49.12 with HTTP; Wed, 14 Sep 2011 13:09:00 -0700 (PDT)
In-Reply-To: <CAB=c7TpFE_28BNpkW27kKK41w8QdaMKJ96=6H=xqonVDdTWUkA@mail.gmail.com>
References: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
<4E6F83C3.9020108@jerviss.org>
<CABsx9T0JvnOaBy+irHtnN1zMWP8FiDTn=kn-01ky+V2MW1suTg@mail.gmail.com>
<CAB=c7TpFE_28BNpkW27kKK41w8QdaMKJ96=6H=xqonVDdTWUkA@mail.gmail.com>
Date: Wed, 14 Sep 2011 16:09:00 -0400
Message-ID: <CAAS2fgQOuNKWD09arSzqKxYFRv95q4xyq0Wz4ZkeKdKSWJ-=kA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Aidan Thornton <makosoft@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.2 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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.4 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1R3vlZ-0007EZ-Rf
Cc: kjj <kjj@jerviss.org>, 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: Wed, 14 Sep 2011 20:09:06 -0000
On Wed, Sep 14, 2011 at 3:52 PM, Aidan Thornton <makosoft@gmail.com> wrote:
> Of course, if only a small percentage of mining power adopts this
> scheme, everyone that does so will presumably be harming themselves by
> doing so since they're essentially increasing the odds that the next
> block they mine will become invalid...
Perhaps better thing to do is to also delay the _forwarding_ of these
blocks _and_ blocks that extend them, until extended one more time.
This policy, if adopted by the forwarding nodes (who really shouldn't
care for much other than the overall health of bitcoins) puts miners
at risk if they don't run the augmented extension policy.
Though I generally agree with Luke that we should just fix the root
cause even though it forks the chain. Not for his reasons (I don't
give a crap about the burden on _one_ pool operator=E2=80=94 the rest cope
with bitcoind scaling fine without excessive dependance on ntime
rolling), but simply because not fixing it makes the bitcoin security
model harder to explain and analyze.
"Here is a vulnerability, but its offset by this workaround" is
inferior to "the system is secure against this kind of attack".
|
