MIME-Version: 1.0
In-Reply-To: <CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
	<CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
Date: Wed, 30 Sep 2015 19:11:56 +0200
Message-ID: <CA+w+GKRKGS=KZrLtiW8Zbn4EQH_TELfQR+TfrADCMXLR22Q+tw@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e013a060615b16d0520fa0703
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

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

Hi Gregory,


> I'm surprised to see this response


Why? I have objected to the idea of soft forks many times. I wrote an
entire article about it in August. I also objected in April 2014, for
instance, where Pieter agreed with me that soft forks can result in ugly
hacks, and that they are "not nice philosophically because they reduce the
security model of former full nodes to SPV without their knowledge" (he
thought they were worth it anyway).

This is not a new debate. If you're surprised, it means only you weren't
paying attention to all the previous times people raised this issue.


> Have I missed a proposal to change BIP101 to be a real hardfork


There's no such thing as a "real" hard fork - don't try and move the goal
posts. SPV clients do not need any changes to do the right thing with BIP
101, they will follow the new chain automatically, so it needs no changes.

Several people have asked several times now: given the very real and widely
acknowledged downsides that come with a soft fork, *what* is the specific
benefit to end users of doing them?

Until that question is answered to my satisfaction I continue to object to
this BIP on the grounds that the deployment creates financial risk
unnecessarily. To repeat: *CLTV does not have consensus at the moment*.

BTW, in the April 2014 thread Pieter's argument was that hard forks are
more risky, which is at least an answer to my question. But he didn't
explain why he thought that. I disagree: the risk level seems lower with a
hard fork because it doesn't lower anyone's security level.

--089e013a060615b16d0520fa0703
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"><div=
>Hi Gregory,</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;m =
surprised to see this response</blockquote><div><br></div><div>Why? I have =
objected to the idea of soft forks many times. I wrote an entire article ab=
out it in August. I also objected in April 2014, for instance, where Pieter=
 agreed with me that soft forks can result in ugly hacks, and that they are=
 &quot;not nice philosophically because they reduce the security model of f=
ormer full nodes to SPV without their knowledge&quot; (he thought they were=
 worth it anyway).</div><div><br></div><div>This is not a new debate. If yo=
u&#39;re surprised, it means only you weren&#39;t paying attention to all t=
he previous times people raised this issue.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">Have I missed a proposal to change BIP101 to be a rea=
l hardfork</blockquote><div><br></div><div>There&#39;s no such thing as a &=
quot;real&quot; hard fork - don&#39;t try and move the goal posts. SPV clie=
nts do not need any changes to do the right thing with BIP 101, they will f=
ollow the new chain automatically, so it needs no changes.</div><div><br></=
div><div>Several people have asked several times now: given the very real a=
nd widely acknowledged downsides that come with a soft fork, <b>what</b>=C2=
=A0is the specific benefit to end users of doing them?=C2=A0</div><div><br>=
</div><div>Until that question is answered to my satisfaction I continue to=
 object to this BIP on the grounds that the deployment creates financial ri=
sk unnecessarily. To repeat:=C2=A0<b>CLTV does not have consensus at the mo=
ment</b>.</div><div><br></div><div>BTW, in the April 2014 thread Pieter&#39=
;s argument was that hard forks are more risky, which is at least an answer=
 to my question. But he didn&#39;t explain why he thought that. I disagree:=
 the risk level seems lower with a hard fork because it doesn&#39;t lower a=
nyone&#39;s security level.<br></div></div></div></div>

--089e013a060615b16d0520fa0703--