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
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
Return-Path: <jannes.faber@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CCFD3FDF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Jan 2016 02:31:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com
[209.85.215.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D64CC8A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Jan 2016 02:31:09 +0000 (UTC)
Received: by mail-lf0-f43.google.com with SMTP id 17so38760344lfz.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Jan 2016 18:31:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=gvbKJfGmWK5I5a3yqv4AK2hyIDHwRyfvFsPATHhHIuI=;
b=ZSj09ZQbkIhT/yNJpaJWoArL26OSCTIFP0BxGgm3KmzyL1ekiO34K2vv9GZJI97RMA
lDChKBQScIy2w1xCSHVXy73WSOg3phVbYAqPfslS8qsmC4LhomAk1f/eX6vLEu8VcnoC
AIj9vuuJD2wEyniNmJMcduBGTu2x0OpgZQRFr/Vst8a0rYouuB3V2CpTktEwdK7USL9B
kCg3QeUkwe5FgmNHuZ28Ll8wc/P/oxWWuwxxsl7UpCiN1PNFfiizOiprfjgLz8xUbTu0
Mml4Jyg7SxfFluVycFYWy5bdy+E9LrbXPjp1SID4TRbU5NhECwuctm1/3kk0ZpzHLego
WYbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to
:content-type;
bh=gvbKJfGmWK5I5a3yqv4AK2hyIDHwRyfvFsPATHhHIuI=;
b=WFQyiuiliysIQ3Kq7lAZVqXJYaQs996aT+lhlJNB+jmG2pdGqLZ5smrp46ywQbDsNY
ICYtm+YRdzZTbcE7hyJoVGlodOy68HD7S3INTzBvIP+Bw+vCJ5tEJYtTaTapPnI8sFEL
521dlWeUHKq1KRBNineOfT1U9jlEyvOoX9s8eN32TLSixBDja1NtDc3wGIkWBJ+ATiYS
8a7t4CVTZKP2OJDjTmpbNTwMTTUq6/CzO8S+OUxfQ5ZC6icmxkHnXASZYIiG2OhXXjge
R/7gHffBsiAxBXtUtxMc1txEqkvRCVgoTYz24/iz2+IZqNYZZH7enijDMRnExBTUSMlc
bXag==
X-Gm-Message-State: AG10YOTSRaTpH96aPVaMqwDqyCGx/SnMMEF0Y6ztMOrsTAVfBgQzGsm2npvFQeKz3RHz7Q==
X-Received: by 10.25.21.29 with SMTP id l29mr241922lfi.123.1454034668261;
Thu, 28 Jan 2016 18:31:08 -0800 (PST)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com.
[209.85.217.169]) by smtp.gmail.com with ESMTPSA id
l129sm1754885lfl.37.2016.01.28.18.31.07
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 28 Jan 2016 18:31:07 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id dx2so33749062lbd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Jan 2016 18:31:07 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.137.41 with SMTP id qf9mr2358093lbb.140.1454034666577;
Thu, 28 Jan 2016 18:31:06 -0800 (PST)
Received: by 10.112.211.161 with HTTP; Thu, 28 Jan 2016 18:31:05 -0800 (PST)
Received: by 10.112.211.161 with HTTP; Thu, 28 Jan 2016 18:31:05 -0800 (PST)
Date: Fri, 29 Jan 2016 03:31:05 +0100
X-Gmail-Original-Message-ID: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
Message-ID: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
From: Jannes Faber <jannes.faber@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e01177191cb73bc052a6fd301
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 29 Jan 2016 03:41:23 +0000
Subject: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2016 02:31:10 -0000
--089e01177191cb73bc052a6fd301
Content-Type: text/plain; charset=UTF-8
Hi,
Question if you'll allow me. This is not about Gavin's latest hard fork
proposal but in general about any hard (or soft) fork.
I was surprised to see a period expressed in human time instead of in block
time:
> Blocks with timestamps greater than or equal to the triggering block's
timestamp plus 28 days (60*60*24*28 seconds) shall have the new limits.
But even more so I would expect there to be significant differences in
effects on non-updated clients depending on the moment (expressed as block
number) of applying the new rules. I see a few options, all relating to the
2016 blocks recalibration window.
1) the first block after difficulty adjustment.
2) the last block before the difficulty adjustment.
3) in the middle
4) n blocks before the adjustment with n the smallest number of blocks
calculated such that the adjustment can just manage to do the maximum
possible drop in difficulty.
One of the effects I'm thinking of would be in case of an evil contentious
75-25 hard fork. If that activates at 1) or 2) it will take an awful long
time for the 25% chain to get to 2016 for the next adjustment all the while
having 40 minutes block times. Option 4) sounds a lot better for the
conservative chain. The attacking fork clearly has a choice to make it as
hard as possible for them.
On the other hand when a non-contentious hard fork is rolled out, one could
argue that it's actually best for everyone if the remaining 1% chain
doesn't stand a chance of ever reaching 2016 blocks anymore (not even by a
decent sized attacker trying to double spend on stragglers). Also causing
all alarm bells to go off in the non-updated clients.
Have people thought through all the different scenarios yet?
And would it not make sense to define whatever the best choice is as
mandatory for any hard fork proposal? BIP9? (Realising attackers won't
necessarily follow BIPs anyway.)
Does something like this also play a role for soft forks?
I do realise that it's quite possible for the first few blocks, mined after
the new rules become valid, to still be old style blocks. Thus maybe
defeating the whole planning.
--089e01177191cb73bc052a6fd301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Hi,</p>
<p dir=3D"ltr">Question if you'll allow me. This is not about Gavin'=
;s latest hard fork proposal but in general about any hard (or soft) fork.<=
/p>
<p dir=3D"ltr">I was surprised to see a period expressed in human time inst=
ead of in block time:</p>
<p dir=3D"ltr">> Blocks with timestamps greater than or equal to the tri=
ggering block's timestamp plus 28 days (60*60*24*28 seconds) shall have=
the new limits.</p>
<p dir=3D"ltr">But even more so I would expect there to be significant diff=
erences in effects on non-updated clients depending on the moment (expresse=
d as block number) of applying the new rules. I see a few options, all rela=
ting to the 2016 blocks recalibration window.</p>
<p dir=3D"ltr">1) the first block after difficulty adjustment.<br>
2) the last block before the difficulty adjustment.<br>
3) in the middle<br>
4) n blocks before the adjustment with n the smallest number of blocks calc=
ulated such that the adjustment can just manage to do the maximum possible =
drop in difficulty.</p>
<p dir=3D"ltr">One of the effects I'm thinking of would be in case of a=
n evil contentious 75-25 hard fork. If that activates at 1) or 2) it will t=
ake an awful long time for the 25% chain to get to 2016 for the next adjust=
ment all the while having 40 minutes block times. Option 4) sounds a lot be=
tter for the conservative chain. The attacking fork clearly has a choice to=
make it as hard as possible for them.</p>
<p dir=3D"ltr">On the other hand when a non-contentious hard fork is rolled=
out, one could argue that it's actually best for everyone if the remai=
ning 1% chain doesn't stand a chance of ever reaching 2016 blocks anymo=
re (not even by a decent sized attacker trying to double spend on straggler=
s). Also causing all alarm bells to go off in the non-updated clients.</p>
<p dir=3D"ltr">Have people thought through all the different scenarios yet?=
</p>
<p dir=3D"ltr">And would it not make sense to define whatever the best choi=
ce is as mandatory for any hard fork proposal? BIP9? (Realising attackers w=
on't necessarily follow BIPs anyway.)</p>
<p dir=3D"ltr">Does something like this also play a role for soft forks?</p=
>
<p dir=3D"ltr">I do realise that it's quite possible for the first few =
blocks, mined after the new rules become valid, to still be old style block=
s. Thus maybe defeating the whole planning.</p>
--089e01177191cb73bc052a6fd301--
|
