MIME-Version: 1.0
In-Reply-To: <CABm2gDrcrtZLQE8Q9ZuxsWEfD_mFhdBz36x3RCPrQtbBi1455A@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>
	<CABm2gDrcrtZLQE8Q9ZuxsWEfD_mFhdBz36x3RCPrQtbBi1455A@mail.gmail.com>
Date: Tue, 29 Sep 2015 14:07:24 +0200
Message-ID: <CA+w+GKSTC_4Ugpvcb88QxusyBixmzXaTckq0Fx5v3NpgBzjMwg@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=089e011767bf23e9a90520e1a8d3
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

--089e011767bf23e9a90520e1a8d3
Content-Type: text/plain; charset=UTF-8

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?

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?

--089e011767bf23e9a90520e1a8d3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Jorge,<br><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Yes, there is a =
difference. Assuming the hashrate majority upgrades, in the case of a softf=
ork [snip] ...... In the case of a hardfork [snip]<br></p></blockquote><div=
>Yes, I know what the difference between them is at a technical level. You =
didn&#39;t explain why this would make any difference to how fast miners up=
grade. The amount of money they lose in both cases is identical: they are e=
qually incentivised to upgrade with both fork types.</div><div><br></div><d=
iv>Additionally, you say in a hard fork the other chain may &quot;continue =
forever&quot;. Why do you think this is not true for miners building invali=
d blocks on top of the main chain? Why would that not continue forever?</di=
v><div><br></div><div>There just isn&#39;t any difference between the two f=
ork types in terms of how fast miners would upgrade. Heck if anything, a ha=
rd fork should promote faster upgrades, because if a miner isn&#39;t paying=
 attention to their debug.log they might miss the warnings. A soft fork wou=
ld 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 differe=
nt height to everyone else, which is easily detectable by just checking a b=
lock explorer.</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">This disc=
ussion about the general desirability of softforks seems offtopic for the c=
oncrete cltv deployment discussion, which assumes softforks as deployment m=
echanism (just like bip66 assumed it).<br></p>
</blockquote></div>Isn&#39;t that circular? This thread is about deployment=
 of CLTV, but the BIP assumes a particular mechanism, so pointing out probl=
ems with it is off topic? Why have a thread at all?</div></div>

--089e011767bf23e9a90520e1a8d3--