Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

["Jorge Timón" <jtimon@jtimon.cc>]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

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).

[-- Attachment #2: Type: text/html, Size: 1901 bytes --]