MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

--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, &quot;Mike Hearn via bitcoin-dev&quot; &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br>
&gt;&gt; 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>
&gt;<br>
&gt;<br>
&gt; There isn&#39;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>
&gt;<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&#39;s not to say softforks are always preferrable. There&#39;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--