MIME-Version: 1.0
In-Reply-To: <4965E9A0-0FF1-4A3F-9165-A21AF976E229@gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
	<CALqxMTFEme9gYHTAVVLtFc4JCK4hoBLXEhMCRdEXK9cWso_pUA@mail.gmail.com>
	<CA+w+GKQ8xos6S_BBMqZy6wieFCG=eNxahKXrx3mVKuZcxzjruw@mail.gmail.com>
	<4965E9A0-0FF1-4A3F-9165-A21AF976E229@gmail.com>
Date: Mon, 28 Sep 2015 14:26:17 +0200
Message-ID: <CA+w+GKSm2Np92+NA77nNMB5LqSyO0=W8dziiMtGO=Jf+7KidHQ@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bdc0d9ce040170520cdcd00
Cc: Mike Hearn via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

--047d7bdc0d9ce040170520cdcd00
Content-Type: text/plain; charset=UTF-8

>
> Go ahead and object to soft forks...but at least try not to make arguments
> based on changing the definitions of terms we all generally agree upon.
>

I don't intend to do that, and I don't think I am - I know what the
difference between a soft and hard fork is and am not trying to confuse or
blur the two.

To reiterate: this current BIP implements a soft fork. I am not debating
that. I am saying it should use a hard fork instead. This will ensure no
repeat of the P2SH case where invalid blocks were being found for weeks (or
was it months?) after the new rules kicked in, thus exposing SPV wallets
and old nodes to unnecessary risk for no benefit.

Additionally, I am making it clear that there's no consensus for rolling
out the new opcode in this way. As you say, the mechanism has issues. If
you read the comments when I wrote my article, you can see that others
share the same concerns:

https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_hearn

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div>Go ahead and object to soft forks...but at least try not =
to make arguments based on changing the definitions of terms we all general=
ly agree upon.</div></blockquote><div><br></div><div>I don&#39;t intend to =
do that, and I don&#39;t think I am - I know what the difference between a =
soft and hard fork is and am not trying to confuse or blur the two.</div><d=
iv><br></div><div>To reiterate: this current BIP implements a soft fork. I =
am not debating that. I am saying it should use a hard fork instead. This w=
ill ensure no repeat of the P2SH case where invalid blocks were being found=
 for weeks (or was it months?) after the new rules kicked in, thus exposing=
 SPV wallets and old nodes to unnecessary risk for no benefit.</div><div><b=
r></div><div>Additionally, I am making it clear that there&#39;s no consens=
us for rolling out the new opcode in this way. As you say, the mechanism ha=
s issues. If you read the comments when I wrote my article, you can see tha=
t others share the same concerns:</div><div><br></div><div><a href=3D"https=
://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_forks_by_mike_=
hearn">https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensus_and_fo=
rks_by_mike_hearn</a><br></div><div><br></div><div><br></div></div></div></=
div>

--047d7bdc0d9ce040170520cdcd00--