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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Z6MKQ-0001YY-AB
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 17:13:14 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.45 as permitted sender)
client-ip=209.85.215.45; envelope-from=pieter.wuille@gmail.com;
helo=mail-la0-f45.google.com;
Received: from mail-la0-f45.google.com ([209.85.215.45])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z6MKP-0006NH-C6
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 17:13:14 +0000
Received: by lacny3 with SMTP id ny3so89787906lac.3
for <bitcoin-development@lists.sourceforge.net>;
Sat, 20 Jun 2015 10:13:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.37.67 with SMTP id w3mr22841029laj.123.1434820387024;
Sat, 20 Jun 2015 10:13:07 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Sat, 20 Jun 2015 10:13:06 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Sat, 20 Jun 2015 10:13:06 -0700 (PDT)
In-Reply-To: <CAPg+sBijQ0Q9U00hUaotYujqW8M+v1ED+PV+ap2g7b0Z4=RNSA@mail.gmail.com>
References: <CAPg+sBijQ0Q9U00hUaotYujqW8M+v1ED+PV+ap2g7b0Z4=RNSA@mail.gmail.com>
Date: Sat, 20 Jun 2015 19:13:06 +0200
Message-ID: <CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0158ba0a7c36090518f627bf
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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1Z6MKP-0006NH-C6
Subject: [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:13:14 -0000
--089e0158ba0a7c36090518f627bf
Content-Type: text/plain; charset=UTF-8
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
--089e0158ba0a7c36090518f627bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Hello 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>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
--089e0158ba0a7c36090518f627bf--
|
