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

[Jorge Timón]

On Tue, Sep 29, 2015 at 2:07 PM, Mike Hearn <hearn at vinumeris.com> wrote:
> Hi Jorge,
>
>> Yes, there is a difference. Assuming the hashrate majority upgrades, in
>> the case of a softfork [snip] ...... In the case of a hardfork [snip]
>
> Yes, I know what the difference between them is at a technical level. You
> didn't explain why this would make any difference to how fast miners
> upgrade. The amount of money they lose in both cases is identical: they are
> equally incentivised to upgrade with both fork types.
>
> Additionally, you say in a hard fork the other chain may "continue forever".
> Why do you think this is not true for miners building invalid blocks on top
> of the main chain? Why would that not continue forever?

I didn't talked about how fast miners would upgrade, please read again
because I believe I was extremely precise.
In both cases I'm assuming there's a minority of the hasrate which
doesn't upgrade.
In the softfork case, the minority will always build on top of the
longest chain (which is valid to them). There may be many little
alternative chains that are ignored (and orphaned) by the upgraded
miners, but non-upgraded miners will always build on top of the
longest chain.

In the hardfork case, non-upgraded miners will reject the upgraded
chain because it is invalid to them, so they will build on top of the
longest non-upgraded chains.
Two alternative chains will continue growing forever unless the
non-upgraded miners eventually upgrade.
In contrast, there won't be 2 alternative chains growing forever in
the softfork case even if the minority miners never upgrade.

> There just isn't any difference between the two fork types in terms of how
> fast miners would upgrade. Heck if anything, a hard fork should promote
> faster upgrades, because if a miner isn't paying attention to their
> debug.log they might miss the warnings. A soft fork would then look
> identical to a run of really bad luck, which can legitimately happen from
> time to time. A hard fork results in your node having a different height to
> everyone else, which is easily detectable by just checking a block explorer.
>>
>> 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).
>
> Isn't that circular? This thread is about deployment of CLTV, but the BIP
> assumes a particular mechanism, so pointing out problems with it is off
> topic? Why have a thread at all?

BIP99 recommends an uncontroversial softfork for this kind of case.
You seem to be contradicting BIP99 in many other places. Maybe you
want to complain about some of the recommendations in BIP99 (instead
of everywhere else):

https://github.com/bitcoin/bips/pull/181

On Wed, Sep 30, 2015 at 2:30 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> This will not change the fact that the rollout strategy is bad and nobody
> has answered my extremely basic question: why is it being done in this way,
> given the numerous downsides?

You seem to be the only one who thinks that softforks have "numerous
downsides" over hardforks.
So everybody just basically disagrees with the assumption in your
question and thus nobody can answer it.