MIME-Version: 1.0
In-Reply-To: <20150928132127.GA4829@savin.petertodd.org>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
	<20150928132127.GA4829@savin.petertodd.org>
Date: Mon, 28 Sep 2015 15:41:56 +0200
Message-ID: <CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7bdc09f66c0db80520cedc60
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

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

>
> 1) Do you agree that CLTV should be added to the Bitcoin protocol?
>
> Ignoring the question how exactly it is added, hard-fork or soft-fork.
>

The opcode definition seems OK.


> 2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it
>    is added to Bitcoin Core?
>

Yes. It might be worth putting the version bit change behind a command line
flag though: the BIP, as written, has problems (with deployment).


> 3) Will you add soft-fork detection to bitcoinj, to allow SPV clients to

   detect advertised soft-forks and correctly handle them?
>

I'd really hate to do that. It'd be a Rube Goldberg machine:

   https://krypt3ia.files.wordpress.com/2011/11/rube.jpg

There's no really good way to do what you propose, and we already have a
perfectly workable mechanism to tell SPV clients about chain forks: the
block chain itself. This has the advantage of being already implemented,
already deployed, and it works correctly.

Attempting to strap a different mechanism on top to try and make soft forks
more like hard forks would be a large and pointless waste of people's time
and effort, not just mine (bitcoinj is not the only widely used SPV
implementation nowadays). You may as well go straight to the correct
outcome instead of trying to simulate it with ever more complex mechanisms.

--047d7bdc09f66c0db80520cedc60
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">1) Do you agree that CLTV should be added to the Bitcoin proto=
col?<br>
<br>
Ignoring the question how exactly it is added, hard-fork or soft-fork.<br><=
/blockquote><div><br></div><div>The opcode definition seems OK.</div><div>=
=C2=A0</div><blockquote 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-s=
tyle:solid;padding-left:1ex">2) Will you add a IsSuperMajority() CLTV soft-=
fork to Bitcoin XT if it<br>
=C2=A0 =C2=A0is added to Bitcoin Core?<br></blockquote><div><br></div><div>=
Yes. It might be worth putting the version bit change behind a command line=
 flag though: the BIP, as written, has problems (with deployment).</div><di=
v>=C2=A0</div><blockquote 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;padding-left:1ex">3) Will you add soft-fork detection to bitco=
inj, to allow SPV clients to=C2=A0</blockquote><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=C2=A0 =C2=
=A0detect advertised soft-forks and correctly handle them?<br></blockquote>=
<div><br></div><div>I&#39;d really hate to do that. It&#39;d be a Rube Gold=
berg machine:</div><div><br></div><div>=C2=A0 =C2=A0<a href=3D"https://kryp=
t3ia.files.wordpress.com/2011/11/rube.jpg">https://krypt3ia.files.wordpress=
.com/2011/11/rube.jpg</a><br></div><div><br></div><div>There&#39;s no reall=
y good way to do what you propose, and we already have a perfectly workable=
 mechanism to tell SPV clients about chain forks: the block chain itself. T=
his has the advantage of being already implemented, already deployed, and i=
t works correctly.</div><div><br></div><div>Attempting to strap a different=
 mechanism on top to try and make soft forks more like hard forks would be =
a large and pointless waste of people&#39;s time and effort, not just mine =
(bitcoinj is not the only widely used SPV implementation nowadays). You may=
 as well go straight to the correct outcome instead of trying to simulate i=
t with ever more complex mechanisms.</div></div></div></div>

--047d7bdc09f66c0db80520cedc60--