From: Pieter Wuille <pieter.wuille@gmail•com>
To: David Vorick <david.vorick@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Hard fork via miner vote
Date: Sat, 20 Jun 2015 20:11:53 +0200 [thread overview]
Message-ID: <CAPg+sBgmGcWF6YHg0rrq8AK3V323fw9mvms3u=RzuP=5j5v6hw@mail.gmail.com> (raw)
In-Reply-To: <CAFVRnyoqdbhGB1LVcawMqviq4ExvoOMM7CfFKSAtDgcZBc1TKw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1775 bytes --]
next prev parent reply other threads:[~2015-06-20 18:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPg+sBijQ0Q9U00hUaotYujqW8M+v1ED+PV+ap2g7b0Z4=RNSA@mail.gmail.com>
2015-06-20 17:13 ` Pieter Wuille
2015-06-20 17:26 ` David Vorick
2015-06-20 18:11 ` Pieter Wuille [this message]
2015-06-20 18:17 ` Matt Whitlock
2015-06-20 17:46 ` Tier Nolan
2015-06-20 18:42 ` Roy Badami
2015-06-20 20:07 ` Roy Badami
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPg+sBgmGcWF6YHg0rrq8AK3V323fw9mvms3u=RzuP=5j5v6hw@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=david.vorick@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox