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
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Z6Mr5-00013B-J5
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 17:46:59 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.170 as permitted sender)
client-ip=209.85.220.170; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f170.google.com;
Received: from mail-qk0-f170.google.com ([209.85.220.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z6Mr4-00029r-EA
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 17:46:59 +0000
Received: by qkbp125 with SMTP id p125so73635983qkb.2
for <bitcoin-development@lists.sourceforge.net>;
Sat, 20 Jun 2015 10:46:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.237.147 with SMTP id i141mr30383143qhc.25.1434822412984;
Sat, 20 Jun 2015 10:46:52 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Sat, 20 Jun 2015 10:46:52 -0700 (PDT)
In-Reply-To: <CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com>
References: <CAPg+sBijQ0Q9U00hUaotYujqW8M+v1ED+PV+ap2g7b0Z4=RNSA@mail.gmail.com>
<CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com>
Date: Sat, 20 Jun 2015 18:46:52 +0100
Message-ID: <CAE-z3OVJbJ=qq3OZvuxWW=17r32aAZf9fRLWd9pHdSw60k7Ftw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1135ad283de7220518f6a074
X-Spam-Score: 0.6 (/)
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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-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
X-Headers-End: 1Z6Mr4-00029r-EA
Subject: Re: [Bitcoin-development] Hard fork via miner vote
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: Sat, 20 Jun 2015 17:46:59 -0000
--001a1135ad283de7220518f6a074
Content-Type: text/plain; charset=UTF-8
I agree giving notice that the change is going to happen is critical for a
hard fork. If miners vote in favor, they need to give people time to
upgrade (or to decide to reject the fork).
The BIP 100 proposal is that no change will happen until a timestamp is
reached. It isn't clear exactly how it would work.
Testnet: Sep 1st 2015
Mainnet: Jan 11th 2016
It suggests 90% of 12000 blocks (~83 days).
This means that if 10800 of the last 12000 blocks are the updated version,
then the change is considered locked in.
I think having an earlier "fail" threshold would be a good idea too. This
guarantees notice.
Assuming 3 is <old rule> and 4 is <new rule>
If the median of 11 timestamp is after 1st Sep 2015 and less than 10800 of
the last 12000 blocks are version 4+, then reject version 4 blocks
If the median of 11 timestamp is after 1st Nov 2015 and at least 10800 of
the last 12000 blocks are version 4+, then reject version 3 blocks
(lock-in)
If the median of 11 timestamp is after 1st Jan 2016 and at least 10800 of
the last 12000 blocks are version 4+, the allow <new rule>
This means that if the 90% threshold is lost at any time between 1st Sep
and 1st Nov, then the fork is rejected. Otherwise, after the 1st Nov, it
is locked in, but the new rules don't activate until 1st Jan.
For block size, miners could still soft fork back to 1MB after 1st Nov, it
there is a user/merchant revolt (maybe that would be version 5 blocks).
On Sat, Jun 20, 2015 at 6:13 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> Hello all,
>
> I've seen ideas around hard fork proposals that involve a block version
> vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
> believe this is a bad idea, independent of what the hard fork itself is.
>
> Ultimately, the purpose of a hard fork is asking the whole community to
> change their full nodes to new code. The purpose of the trigger mechanism
> is to establish when that has happened.
>
> Using a 95% threshold, implies the fork can happen when at least 5% of
> miners have not upgraded, which implies some full nodes have not (as miners
> are nodes), and in addition, means the old chain can keep growing too,
> confusing old non-miner nodes as well.
>
> Ideally, the fork should be scheduled when one is certain nodes will have
> upgraded, and the risk for a fork will be gone. If everyone has upgraded,
> no vote is necessary, and if nodes have not, it remains risky to fork them
> off.
>
> I understand that, in order to keep humans in the loop, you want an
> observable trigger mechanism, and a hashrate vote is an easy way to do
> this. But at least, use a minimum timestamp you believe to be reasonable
> for upgrade, and a 100% threshold afterwards. Anything else guarantees that
> your forking change happens *knowingly* before the risk is gone.
>
> You may argue that miners would be asked to - and have it in their best
> interest - to not actually make blocks that violate the changed rule before
> they are reasonably sure that everyone has upgraded. That is possible, but
> it does not gain you anything over just using a 100% threshold, as how
> would they be reasonably sure everyone has upgraded, while blocks creater
> by non-upgraded miners are still being created?
>
> TL;DR: use a timestamp switchover for a hard fork, or add a block voting
> threshold as a means to keep humans in the loop, but if you do, use 100% as
> threshold.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a1135ad283de7220518f6a074
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div>I agree giving notice that t=
he change is going to happen is critical for a hard fork.=C2=A0 If miners v=
ote in favor, they need to give people time to upgrade (or to decide to rej=
ect the fork).<br></div><div><br>The BIP 100 proposal is that no change wil=
l happen until a timestamp is reached.=C2=A0 It isn't clear exactly how=
it would work.<br><br></div>Testnet: Sep 1st 2015<br></div>Mainnet: Jan 11=
th 2016<br><br></div>It suggests 90% of 12000 blocks (~83 days).<br><br></d=
iv></div>This means that if 10800 of the last 12000 blocks are the updated =
version, then the change is considered locked in.<br><br></div><div>I think=
having an earlier "fail" threshold would be a good idea too.=C2=
=A0 This guarantees notice.<br><br></div><div>Assuming 3 is <old rule>=
; and 4 is <new rule><br><br>If the median of 11 timestamp is after 1=
st Sep 2015 and less than 10800=20
of the last 12000 blocks are version 4+, then reject version 4 blocks<br></=
div><div>If the median of 11 timestamp is after 1st Nov 2015 and at least 1=
0800 of the last 12000 blocks are version 4+, then reject version 3 blocks=
=C2=A0 (lock-in)<br></div><div>If the median of 11 timestamp is after 1st J=
an 2016 and at least 10800 of the last 12000 blocks are version 4+, the all=
ow <new rule><br><br></div><div>This means that if the 90% threshold =
is lost at any time between 1st Sep and 1st Nov, then the fork is rejected.=
=C2=A0 Otherwise, after the 1st Nov, it is locked in, but the new rules don=
't activate until 1st Jan.<br><br></div><div>For block size, miners cou=
ld still soft fork back to 1MB after 1st Nov, it there is a user/merchant r=
evolt (maybe that would be version 5 blocks).<br></div><div><br></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Jun 20, 2015 a=
t 6:13 PM, Pieter Wuille <span dir=3D"ltr"><<a href=3D"mailto:pieter.wui=
lle@gmail.com" target=3D"_blank">pieter.wuille@gmail.com</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir=3D"ltr">Hel=
lo all,</p>
<p dir=3D"ltr">I've seen ideas around hard fork proposals that involve =
a block version vote (a la BIP34, BIP66, or my more recent versionbits BIP =
draft). I believe this is a bad idea, independent of what the hard fork its=
elf is.</p>
<p dir=3D"ltr">Ultimately, the purpose of a hard fork is asking the whole c=
ommunity to change their full nodes to new code. The purpose of the trigger=
mechanism is to establish when that has happened.</p>
<p dir=3D"ltr">Using a 95% threshold, implies the fork can happen when at l=
east 5% of miners have not upgraded, which implies some full nodes have not=
(as miners are nodes), and in addition, means the old chain can keep growi=
ng too, confusing old non-miner nodes as well.</p>
<p dir=3D"ltr">Ideally, the fork should be scheduled when one is certain no=
des will have upgraded, and the risk for a fork will be gone. If everyone h=
as upgraded, no vote is necessary, and if nodes have not, it remains risky =
to fork them off.</p>
<p dir=3D"ltr">I understand that, in order to keep humans in the loop, you =
want an observable trigger mechanism, and a hashrate vote is an easy way to=
do this. But at least, use a minimum timestamp you believe to be reasonabl=
e for upgrade, and a 100% threshold afterwards. Anything else guarantees th=
at your forking change happens *knowingly* before the risk is gone.</p>
<p dir=3D"ltr">You may argue that miners would be asked to - and have it in=
their best interest - to not actually make blocks that violate the changed=
rule before they are reasonably sure that everyone has upgraded. That is p=
ossible, but it does not gain you anything over just using a 100% threshold=
, as how would they be reasonably sure everyone has upgraded, while blocks =
creater by non-upgraded miners are still being created?</p>
<p dir=3D"ltr">TL;DR: use a timestamp switchover for a hard fork, or add a =
block voting threshold as a means to keep humans in the loop, but if you do=
, use 100% as threshold.</p><span class=3D""><font color=3D"#888888">
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
</font></span><br>---------------------------------------------------------=
---------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
<br></blockquote></div><br></div></div>
--001a1135ad283de7220518f6a074--
|
