MIME-Version: 1.0
In-Reply-To: <CADJgMzvCMPCto7fra+H=U3b9hCY7rCPDOV2DgOS4bLzz+PTLUg@mail.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>
	<CADJgMzvCMPCto7fra+H=U3b9hCY7rCPDOV2DgOS4bLzz+PTLUg@mail.gmail.com>
Date: Mon, 28 Sep 2015 16:17:06 +0200
Message-ID: <CA+w+GKRK-_JQ3fEJFcO3t4Pr4HioWfqt-qbtFLxTSEnpLYnopA@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Btc Drak <btcdrak@gmail.com>
Content-Type: multipart/alternative; boundary=001a113fb1e430579d0520cf5abb
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

--001a113fb1e430579d0520cf5abb
Content-Type: text/plain; charset=UTF-8

>
> 2. As for SPV wallets need to handle awareness of the new blocks.
>

There is simply no need for any wallets to change. Making the spec a hard
fork instead of a soft fork means all existing software does the right
thing automatically.

To repeat, please bear in mind that bitcoinj is no longer the only SPV
wallet implementation. BreadWallet has its own code in Objective-C and is
the second most popular SPV implementation (and growing). Additionally,
bitcoinj is incorporated into lots of apps that'd have to have new versions
released, some of which don't have any way to force a user to update.

So it's not just my time you'd waste: it's lots of different people's.

One thing I haven't seen yet is the justification for why a soft fork
should be used here. There's no requirement that it be so, and there are
real downsides. As Eric said, the fact that the mechanism has issues is not
under dispute.

The normal justification for this it's that it's forwards compatible. But
that's not a justification, that's a description.

Re: XT, I already addressed this above.

--001a113fb1e430579d0520cf5abb
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:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote">2. As for SPV wallets need to handle awareness of th=
e new blocks.<br></div></div></div></blockquote><div><br></div><div>There i=
s simply no need for any wallets to change. Making the spec a hard fork ins=
tead of a soft fork means all existing software does the right thing automa=
tically.</div><div><br></div><div>To repeat, please bear in mind that bitco=
inj is no longer the only SPV wallet implementation. BreadWallet has its ow=
n code in Objective-C and is the second most popular SPV implementation (an=
d growing). Additionally, bitcoinj is incorporated into lots of apps that&#=
39;d have to have new versions released, some of which don&#39;t have any w=
ay to force a user to update.</div><div><br></div><div>So it&#39;s not just=
 my time you&#39;d waste: it&#39;s lots of different people&#39;s.</div><di=
v><br></div><div>One thing I haven&#39;t seen yet is the justification for =
why a soft fork should be used here. There&#39;s no requirement that it be =
so, and there are real downsides. As Eric said, the fact that the mechanism=
 has issues is not under dispute.</div><div><br></div><div>The normal justi=
fication for this it&#39;s that it&#39;s forwards compatible. But that&#39;=
s not a justification, that&#39;s a description.</div><div>=C2=A0</div><div=
>Re: XT, I already addressed this above.</div></div></div></div>

--001a113fb1e430579d0520cf5abb--