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
|
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'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--
|
