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

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

On Mon, Sep 28, 2015 at 12:40 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There is no consensus. Now pick. Lose the requirement that everyone agree
> for consensus changes, and tell people you've done it. Change the spec. Or
> do nothing.
>

Of course there is good technical consensus for CLTV by IsSuperMajority()
in the same way as BIP66 was rolled out. I believe the only open question
is whether we have to account for XT's use of versionbits (because the
standard has not been finalised). One can take the view that it is a non
issue given the almost negligible number of BIP101 blocks, but it certainly
goes away if XT also merges BIP65/CLTV.

As for risks, I think we learned a lot from BIP66:

1. miners are now aware of the risks of SPV mining near activation and are
financially incentivised not to during that period.
2. As for SPV wallets need to handle awareness of the new blocks. BitcoinJ
can play a pivotal role: as far as I am aware if we'd thought about adding
handling to BitcoinJ before activation rather than after activation[1][2],
the SPV issues would have been mitigated for the vast majority who rely on
the library. To me, this particular issue highlights our collective failure
to communicate the necessity for additional SPV handling requirements and
other preparation the ecosystem should engage in during a soft fork. This
is something we should definitely add to the release notes for the next
soft fork and advertise widely. Certainly it MUST be well documented in the
BIP65 deployment section, which it is currently not.

Lastly your objections came across very strongly (at least to my
understanding) so I am curious: Peter stated Gavin is OK with adding CLTV
support to XT, and assuming that is the case, will you object to merging it
or similarly object to adding the necessary block handling to BitcoinJ?

[1]
https://github.com/bitcoinj/bitcoinj/commit/6f03669fbd6c368961a25dfd772751d1ca2a1b5b
[2]
https://github.com/bitcoinj/bitcoinj/commit/d3d11df6d71ff11cef2dc0caa8263daa641fe118

--089e013d0f9a6ded400520cf3296
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">On M=
on, Sep 28, 2015 at 12:40 PM, Mike Hearn via bitcoin-dev <span dir=3D"ltr">=
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div>There is no consensus. Now pick. Lose the requirement that everyone a=
gree for consensus changes, and tell people you&#39;ve done it. Change the =
spec. Or do nothing.</div></div></div></div></blockquote><div><br></div><di=
v>Of course there is good technical consensus for CLTV by IsSuperMajority()=
 in the same way as BIP66 was rolled out. I believe the only open question =
is whether we have to account for XT&#39;s use of versionbits (because the =
standard has not been finalised). One can take the view that it is a non is=
sue given the almost negligible number of BIP101 blocks, but it certainly g=
oes away if XT also merges BIP65/CLTV.</div><div><br></div><div>As for risk=
s, I think we learned a lot from BIP66:</div><div><br></div><div>1. miners =
are now aware of the risks of SPV mining near activation and are financiall=
y incentivised not to during that period.=C2=A0</div><div>2. As for SPV wal=
lets need to handle awareness of the new blocks. BitcoinJ can play a pivota=
l role: as far as I am aware if we&#39;d thought about adding handling to B=
itcoinJ before activation rather than after activation[1][2], the SPV issue=
s would have been mitigated for the vast majority who rely on the library. =
To me, this particular issue highlights our collective failure to communica=
te the necessity for additional SPV handling requirements and other prepara=
tion the ecosystem should engage in during a soft fork. This is something w=
e should definitely add to the release notes for the next soft fork and adv=
ertise widely. Certainly it MUST be well documented in the BIP65 deployment=
 section, which it is currently not.</div><div><br></div><div>Lastly your o=
bjections came across very strongly (at least to my understanding) so I am =
curious: Peter stated Gavin is OK with adding CLTV support to XT, and assum=
ing that is the case, will you object to merging it or similarly object to =
adding the necessary block handling to BitcoinJ?</div><div><br></div><div>[=
1]=C2=A0<a href=3D"https://github.com/bitcoinj/bitcoinj/commit/6f03669fbd6c=
368961a25dfd772751d1ca2a1b5b">https://github.com/bitcoinj/bitcoinj/commit/6=
f03669fbd6c368961a25dfd772751d1ca2a1b5b</a><br></div><div>[2]=C2=A0<a href=
=3D"https://github.com/bitcoinj/bitcoinj/commit/d3d11df6d71ff11cef2dc0caa82=
63daa641fe118">https://github.com/bitcoinj/bitcoinj/commit/d3d11df6d71ff11c=
ef2dc0caa8263daa641fe118</a></div><div><br></div></div></div></div>

--089e013d0f9a6ded400520cf3296--