Return-Path: <me@thomaskerin.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 017D3720
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Apr 2017 14:18:30 +0000 (UTC)
X-Greylist: delayed 00:08:10 by SQLgrey-1.7.6
Received: from thomaskerin.io (static.204.212.9.5.clients.your-server.de
	[5.9.212.204])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C958418B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Apr 2017 14:18:27 +0000 (UTC)
Received: from [10.4.86.222] (unknown [82.201.92.138])
	by thomaskerin.io (Postfix) with ESMTPSA id C5E561198101E;
	Wed,  5 Apr 2017 14:10:12 +0000 (UTC)
Date: Wed, 05 Apr 2017 16:09:59 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <2796215.bJP4rN4KYZ@strawberry>
References: <PU5yHaeZtxR5ManpM0q7ZIN1pElEorBfO09u7ZIC-h81mQizYCZ5qNv89Tb2ZLNHbCktmV65q2Xkm1K3UckvVZLOWBMW7-riWYRY4HtFe1A=@protonmail.com>
	<201704041801.51655.luke@dashjr.org>
	<2796215.bJP4rN4KYZ@strawberry>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----X4OLUD5KXQROMDEC268T2R8M7CLKV3"
Content-Transfer-Encoding: 7bit
To: Tom Zander <tomz@freedommail.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Thomas Kerin <me@thomaskerin.io>
Message-ID: <FE6D0125-951A-47D6-A2E4-C161DCB56804@thomaskerin.io>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Generalized version bits voting
	(bip-genvbvoting)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Apr 2017 14:18:30 -0000

------X4OLUD5KXQROMDEC268T2R8M7CLKV3
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

A schism is just that: miners can't ameliorate a HF transition in the way t=
hey can censor transactions without permission=2E This is how miners became=
 a convenient way to activate soft-forks=2E=20

So while BIP9 can indicate the later censorship (a soft fork) in a way tha=
t nodes can follow (or not) a hardfork always requires nodes to upgrade to =
the version increasing the degrees of freedom of the system=2E=20

Signaling is less useful here: the change is not opt-in and will require c=
oordination; and the continuation of the chain thereafter depends on people=
 actually running the hard-fork code, not just being aware there is somethi=
ng happening=2E


On 04/05/2017 12:08 PM, Tom Zander via bitcoin-dev wrote:

On Tuesday, 4 April 2017 20:01:51 CEST Luke Dashjr via bitcoin-dev wrote:=
=20

BIP 9 provides a mechanism for having miners coordinate softforks because =
they can make the upgrade process smoother this way=2E But the same is not =
true of hardforks: miners are essentially irrelevant to them, and cannot ma=
ke the process any smoother=2E=20

Can you explain how miners are irrelevant if the upgrade is not a soft for=
k?=20



--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
------X4OLUD5KXQROMDEC268T2R8M7CLKV3
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

A schism is just that: miners can&#39;t ameliorate a HF transition in the w=
ay they can censor transactions without permission=2E This is how miners be=
came a convenient way to activate soft-forks=2E <br>
<br>
So while BIP9 can indicate the later censorship (a soft fork) in a way tha=
t nodes can follow (or not) a hardfork always requires nodes to upgrade to =
the version increasing the degrees of freedom of the system=2E <br>
<br>
Signaling is less useful here: the change is not opt-in and will require c=
oordination; and the continuation of the chain thereafter depends on people=
 actually running the hard-fork code, not just being aware there is somethi=
ng happening=2E<br>
<br>
<br>
On 04/05/2017 12:08 PM, Tom Zander via bitcoin-dev wrote:<br>
<br>
On Tuesday, 4 April 2017 20:01:51 CEST Luke Dashjr via bitcoin-dev wrote: =
<br>
<br>
BIP 9 provides a mechanism for having miners coordinate softforks because =
they can make the upgrade process smoother this way=2E But the same is not =
true of hardforks: miners are essentially irrelevant to them, and cannot ma=
ke the process any smoother=2E <br>
<br>
Can you explain how miners are irrelevant if the upgrade is not a soft for=
k? <br>
<br>
<br>
<br>
-- <br>
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
------X4OLUD5KXQROMDEC268T2R8M7CLKV3--