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
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B2EB91C7C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 23:17:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
[209.85.212.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1D17422A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 23:17:18 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so122386725wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 16:17:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=rbwUkG1Y/Sik3Yp3ZFvGLLBsQ7a6/8WpFsCBHd0cYNk=;
b=lVaYZd7Ts+7pIkPXrMcbw3r1wyqAnuudmlpqHEEXE5/WqZt4vSOungEJaokGz4hFBW
BcfFsdlsgZITN4y/M0hE5SDLnoMZse+I9t0jhBp8X1qGvMRN887wbiW3rpDVZr3FuQ3Y
cvztrPso3SxB0OaHrA/vZfj0L0o9mRycokGFsh9KiQ30bTJx++ad5jm4tienBdIoE38F
ywi2W4xWTjgIFqJjAJGQ8UEggl4bWU9MoaEl09jN9mnxj6q8pAlyF0pAVDD5Sm+hPu+Z
Zu+ub6G1w/mjXeZOhGgdoJG3pAVWc1dAkZHRZn0kCm0Z29JrKnyg07CDrJ56IFIPnsg3
KWVw==
X-Gm-Message-State: ALoCoQluMlqMbCxKY0ySRRYwXicN9a0av/Y1zdmaet3ujjtExQSwNxlC3LvmdqZk8QrwB1l/04KT
MIME-Version: 1.0
X-Received: by 10.180.92.201 with SMTP id co9mr3079413wib.58.1443482236607;
Mon, 28 Sep 2015 16:17:16 -0700 (PDT)
Received: by 10.194.114.199 with HTTP; Mon, 28 Sep 2015 16:17:15 -0700 (PDT)
Received: by 10.194.114.199 with HTTP; Mon, 28 Sep 2015 16:17:15 -0700 (PDT)
In-Reply-To: <CA+w+GKRcUYsKzG8n5ut-ObD1MM9bs0OD-jdHe1+cLkcO6B7wKg@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<20150928132127.GA4829@savin.petertodd.org>
<CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com>
<20150928142953.GC21815@savin.petertodd.org>
<CA+w+GKTUz2eVJOpixSebWiQ59ovoELNhsZWSsbLHXWqk2eCn0A@mail.gmail.com>
<20150928144318.GA28939@savin.petertodd.org>
<CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com>
<20150928150543.GB28939@savin.petertodd.org>
<CA+w+GKTPKxGWWN28_hzR8BoCh11exvgZm4s-_=5oFWd-R62uyA@mail.gmail.com>
<8461c6195ca65ce7355f693fa24bb177@xbt.hk>
<CA+w+GKRcUYsKzG8n5ut-ObD1MM9bs0OD-jdHe1+cLkcO6B7wKg@mail.gmail.com>
Date: Tue, 29 Sep 2015 01:17:15 +0200
Message-ID: <CABm2gDrcrtZLQE8Q9ZuxsWEfD_mFhdBz36x3RCPrQtbBi1455A@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=f46d043c7ff2f3f3840520d6e536
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Mon, 28 Sep 2015 23:17:18 -0000
--f46d043c7ff2f3f3840520d6e536
Content-Type: text/plain; charset=UTF-8
On Sep 28, 2015 7:14 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>> In a hardfork, however, there is no mechanism to stop the old fork and
we may have 2 chains co-exist for a long time.
>
>
> There isn't any difference in how long the divergent state exists for.
That depends only on how fast people upgrade, which is unaffected by the
rollout strategy used.
>
Yes, there is a difference. Assuming the hashrate majority upgrades, in the
case of a softfork non-upgraded miners will try to build on top of the
longest chain (the upgraded one) but their blocks will get consistently
orphaned for having a too old block version (and if they just increment the
version without implementing the new restrictions, then their blocks will
be orphaned when they fail to enforce the new restrictions). In the case of
a hardfork, the non-upgraded miners will keep on building their own longest
valid chain (the upgraded chain is not valid in their eyes), potentially
forever.
That's not to say softforks are always preferrable. There's cases when a
feature can be implemented as a softfork or a hardfork, but the softfork
solution is clearly inferior and introduces technical debt.
In those cases I prefer a hardfork, but this is not one of those cases.
In any case, maybe you want to provide some feedback to bip99, which is
about possible consensus rule changes scenarios and a recommended
deployment path for each of them (softforks and hardforks are subdivided in
several types). This discussion about the general desirability of softforks
seems offtopic for the concrete cltv deployment discussion, which assumes
softforks as deployment mechanism (just like bip66 assumed it).
--f46d043c7ff2f3f3840520d6e536
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Sep 28, 2015 7:14 PM, "Mike Hearn via bitcoin-dev" <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<br>
>> In a hardfork, however, there is no mechanism to stop the old fork=
and we may have 2 chains co-exist for a long time.<br>
><br>
><br>
> There isn't any difference in how long the divergent state exists =
for. That depends only on how fast people upgrade, which is unaffected by t=
he rollout strategy used.<br>
><br>
<br>
Yes, there is a difference. Assuming the hashrate majority upgrades, in the=
case of a softfork non-upgraded miners will try to build on top of the lon=
gest chain (the upgraded one) but their blocks will get consistently orphan=
ed for having a too old block version (and if they just increment the versi=
on without implementing the new restrictions, then their blocks will be orp=
haned when they fail to enforce the new restrictions). In the case of a har=
dfork, the non-upgraded miners will keep on building their own longest vali=
d chain (the upgraded chain is not valid in their eyes), potentially foreve=
r.<br>
That's not to say softforks are always preferrable. There's cases w=
hen a feature can be implemented as a softfork or a hardfork, but the softf=
ork solution is clearly inferior and introduces technical debt. <br>
In those cases I prefer a hardfork, but this is not one of those cases.</p>
<p dir=3D"ltr">In any case, maybe you want to provide some feedback to bip9=
9, which is about possible consensus rule changes scenarios and a recommend=
ed deployment path for each of them (softforks and hardforks are subdivided=
in several types). This discussion about the general desirability of softf=
orks seems offtopic for the concrete cltv deployment discussion, which assu=
mes softforks as deployment mechanism (just like bip66 assumed it).</p>
--f46d043c7ff2f3f3840520d6e536--
|
