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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Z6NFK-0005O4-3u
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 18:12:02 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.53 as permitted sender)
client-ip=209.85.215.53; envelope-from=pieter.wuille@gmail.com;
helo=mail-la0-f53.google.com;
Received: from mail-la0-f53.google.com ([209.85.215.53])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z6NFI-0003R8-8p
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 18:12:02 +0000
Received: by lagi2 with SMTP id i2so662724lag.2
for <bitcoin-development@lists.sourceforge.net>;
Sat, 20 Jun 2015 11:11:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.55.70 with SMTP id q6mr22142274lbp.99.1434823913570;
Sat, 20 Jun 2015 11:11:53 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Sat, 20 Jun 2015 11:11:53 -0700 (PDT)
In-Reply-To: <CAFVRnyoqdbhGB1LVcawMqviq4ExvoOMM7CfFKSAtDgcZBc1TKw@mail.gmail.com>
References: <CAPg+sBijQ0Q9U00hUaotYujqW8M+v1ED+PV+ap2g7b0Z4=RNSA@mail.gmail.com>
<CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com>
<CAFVRnyoqdbhGB1LVcawMqviq4ExvoOMM7CfFKSAtDgcZBc1TKw@mail.gmail.com>
Date: Sat, 20 Jun 2015 20:11:53 +0200
Message-ID: <CAPg+sBgmGcWF6YHg0rrq8AK3V323fw9mvms3u=RzuP=5j5v6hw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: David Vorick <david.vorick@gmail.com>
Content-Type: multipart/alternative; boundary=001a1133d13caf09210518f6f951
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: 1Z6NFI-0003R8-8p
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 18:12:02 -0000
--001a1133d13caf09210518f6f951
Content-Type: text/plain; charset=UTF-8
On Sat, Jun 20, 2015 at 7:26 PM, David Vorick <david.vorick@gmail.com>
wrote:
> I see it as unreasonable to expect all nodes to upgrade during a hardfork.
> If you are intentionally waiting for that to happen, it's possible for an
> extreme minority of nodes to hold the rest of the network hostage by simply
> refusing to upgrade. However you want nodes to be able to protest until it
> is clear that they have lost the battle without being at risk of getting
> hardforked out of the network unexpectedly.
>
You can't observe the majority of nodes, only miners, and weighed by
hashrate. If you need a mechanism for protest, that should happen before
the hard fork change code is rolled out. I am assuming a completely
uncontroversial change, in order to not confuse this discussion with the
debate about what hard forks should be done.
So I am not talking about protest, just about deploying a change. And yes,
it is unreasonable to expect that every single node will upgrade. But there
is a difference between ignoring old unmaintained nodes that do not
influence anyone's behaviour, and ignoring the nodes that power miners
producing actual blocks. In addition, having no blocks on the old chain is
safer than producing a small number, as you want full nodes that have not
noticed the fork to fail rather than see a slow but otherwise functional
chain.
--
Pieter
--001a1133d13caf09210518f6f951
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sat, Jun 20, 2015 at 7:26 PM, David Vorick <span dir=3D=
"ltr"><<a href=3D"mailto:david.vorick@gmail.com" target=3D"_blank">david=
.vorick@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
I see it as unreasonable to expect all nodes to upgrade during a hardfork. =
If you are intentionally waiting for that to happen, it's possible for =
an extreme minority of nodes to hold the rest of the network hostage by sim=
ply refusing to upgrade. However you want nodes to be able to protest until=
it is clear that they have lost the battle without being at risk of gettin=
g hardforked out of the network unexpectedly.<br></div></div></blockquote><=
div><br></div><div>You can't observe the majority of nodes, only miners=
, and weighed by hashrate. If you need a mechanism for protest, that should=
happen before the hard fork change code is rolled out. I am assuming a com=
pletely uncontroversial change, in order to not confuse this discussion wit=
h the debate about what hard forks should be done.<br><br></div><div>So I a=
m not talking about protest, just about deploying a change. And yes, it is =
unreasonable to expect that every single node will upgrade. But there is a =
difference between ignoring old unmaintained nodes that do not influence an=
yone's behaviour, and ignoring the nodes that power miners producing ac=
tual blocks. In addition, having no blocks on the old chain is safer than p=
roducing a small number, as you want full nodes that have not noticed the f=
ork to fail rather than see a slow but otherwise functional chain.<br><br>-=
- <br></div><div>Pieter<br></div><div><br></div></div></div></div>
--001a1133d13caf09210518f6f951--
|
