From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Sat, 20 Jun 2015 20:11:53 +0200 Message-ID: From: Pieter Wuille To: David Vorick 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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 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.
<= 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.

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.

-= -
Pieter

--001a1133d13caf09210518f6f951--