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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5D648C9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Jan 2016 16:39:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com
[209.85.217.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5A26112E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Jan 2016 16:39:16 +0000 (UTC)
Received: by mail-lb0-f179.google.com with SMTP id x4so44493807lbm.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Jan 2016 08:39:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=4xwcivgrPSSR70psc2+/q4ZnsRje5HsFQW4930nPV0M=;
b=znHPtlsICg0kGBy5p68sVw3qaRqwH3x6EeJizcdSqA+Thy6i/vz5rnsGjEJHFhWbz7
uFp+zt08wfk2JDBmcGIUpTzB2wS3HtbvO7tKHQI13jie47bSuLd25OOojbQKcMHL9PWv
oVPigGXimgo7CyF9kiGLnFjQ9RSrmyhbc0e7I6/O4Kg0bFqrqf/CjUZwTYKmj0dgUaFo
qaxvpIoviECLWuDBnRUpB4WMN2bum1ALeIcqx05Lou9G45VAXVDFAX7OQ6geF8kKU9Sk
/ixvnT0NgXvu1fC0ajpJh20DX7DadBGpovwET6RIRMdfd79/xWuMpck6iKBlA3ejI+8P
jS9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=4xwcivgrPSSR70psc2+/q4ZnsRje5HsFQW4930nPV0M=;
b=BjjJ4j542lk5HfTMaBVD4/b4/kiZQf5PrcvaUi0YfvqxyiD/ajqBlXZl713DraqGOT
QyxyfxAM5MtzOF3yG9wHOU/9pN0PwwfsjJ1LsV7Ur+whWl3XtRs+teVj0TaNGAWVlsQn
0dkJBzl6RoAgHXfj/KL+QhwAOIJ16m3DN06MCq1a8tu1GTHZXgx2YHC0gXD9cYugaJQk
UfDDHYuJQ5C+kV3XOrMbstCKhsqXCnNdxoGP6P2LWUUWxsSAd3OqGpKv2FQ4OhGGIX3Y
QyXDYXeZkPwN69btT2wX57xJZ4b1Q+PSM3i32rpjgHO0C7ROw5syhfPYHj+S66LNcOi+
+Jrw==
X-Gm-Message-State: AG10YOScC3139SdNccvu0ZmBxF/d6q4Zcb7dIvfIGqrZ13JyMHS1xNOzOFz1fbfM81h7kln+982UywUbyf91DQ==
MIME-Version: 1.0
X-Received: by 10.112.144.226 with SMTP id sp2mr3661807lbb.70.1454085554760;
Fri, 29 Jan 2016 08:39:14 -0800 (PST)
Received: by 10.25.79.208 with HTTP; Fri, 29 Jan 2016 08:39:14 -0800 (PST)
In-Reply-To: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
References: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
Date: Fri, 29 Jan 2016 11:39:14 -0500
Message-ID: <CABsx9T0oY2OuPCRgnQmqbLOBSQVd-yuQ8mMXjfzYpJTjXn8woQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Jannes Faber <jannes.faber@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b342fd4f6f815052a7bacf4
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 16:57:33 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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 16:39:17 -0000
--047d7b342fd4f6f815052a7bacf4
Content-Type: text/plain; charset=UTF-8
On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.
>
>
Block timestamps are in the 80-byte block header, so activation is
completely deterministic and can be determined from just the sequence of
block headers. There are no edge cases to worry about.
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.
>
It doesn't matter much where in the difficulty period the fork happens; if
it happens in the middle, the lower-power fork's difficulty will adjust a
little quicker.
Example: (check my math, I'm really good at screwing up at basic
arithmetic):
Fork at block%2016: 25% hashpower will take 8 weeks to produce 2016
blocks, difficulty drops by 4.
Fork one-week (halfway) into difficulty period: 25% hashpower will take 4
weeks to adjust, difficulty drops by 5/2 = 2.5
It will then take another 3.2 weeks to get to the next difficult adjustment
period and normal 10-minute blocks.
That's an unrealisitic scenario, though-- there will not be 25% of hash
power on a minority fork. I wrote about why in a blog post today:
http://gavinandresen.ninja/minority-branches
If you assume a more realistic single-digit-percentage of hash power on the
minority fork, then the numbers get silly (e.g. two or three months of an
hour or three between blocks before a difficulty adjustment).
--
--
Gavin Andresen
--047d7b342fd4f6f815052a7bacf4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bit=
coin-dev=C2=A0<span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a>></span>=C2=A0wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><p dir=3D"ltr">Hi,</p><p dir=
=3D"ltr">Question if you'll allow me. This is not about Gavin's lat=
est 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 instead=
of in block time:</p><p dir=3D"ltr">> Blocks with timestamps greater th=
an or equal to the triggering block's timestamp plus 28 days (60*60*24*=
28 seconds) shall have the new limits.</p><div><br></div></blockquote><div>=
=C2=A0</div></div><div>Block timestamps are in the 80-byte block header, so=
activation is completely deterministic and can be determined from just the=
sequence of block headers. There are no edge cases to worry about.</div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><p dir=3D"ltr">But even more so I would expec=
t there to be significant differences in effects on non-updated clients dep=
ending 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.=
</p></blockquote><div><br></div><div>It doesn't matter much where in th=
e difficulty period the fork happens; if it happens in the middle, the lowe=
r-power fork's difficulty will adjust a little quicker.</div><div><br><=
/div><div>Example: =C2=A0(check my math, I'm really good at screwing up=
at basic arithmetic):</div><div><br></div><div>Fork at block%2016: =C2=A02=
5% hashpower will take 8 weeks to produce 2016 blocks, difficulty drops by =
4.</div><div><br></div><div>Fork one-week (halfway) into difficulty period:=
=C2=A025% hashpower will take 4 weeks to adjust, difficulty drops by 5/2 =
=3D 2.5</div><div>It will then take another 3.2 weeks to get to the next di=
fficult adjustment period and normal 10-minute blocks.<br></div><div><br></=
div><div>That's an unrealisitic scenario, though-- there will not be 25=
% of hash power on a minority fork. I wrote about why in a blog post today:=
</div><div><br></div><div><a href=3D"http://gavinandresen.ninja/minority-br=
anches">http://gavinandresen.ninja/minority-branches</a><br></div><div><br>=
</div><div>If you assume a more realistic single-digit-percentage of hash p=
ower on the minority fork, then the numbers get silly (e.g. two or three mo=
nths of an hour or three between blocks before a difficulty adjustment).</d=
iv><div><br></div><div class=3D"gmail_extra"><div><br></div>-- <br><div cla=
ss=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>--<br>Ga=
vin Andresen<br></div><div><br></div></div></div></div></div>
</div></div>
--047d7b342fd4f6f815052a7bacf4--
|
