MIME-Version: 1.0
References: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
	<BLU436-SMTP132FA09C343ACB7C82E6C98C64B0@phx.gbl>
	<CA+w+GKT0Th4Tpk=cCxfJwsMdB5NLrARACU3_qiRn4Ns7z_PXYQ@mail.gmail.com>
	<CADm_WcaVbj98G9acqbwUxYudHhWh01FLpm5KgL3rqHffd5WCXg@mail.gmail.com>
	<CA+w+GKTkos5gwZmN_1c7wUFmJgZMJGzZbaZeWO=Rwt3Ta3Zbzw@mail.gmail.com>
	<CABm2gDp1r78OtM=MfHqvV17-6N=nCG+hFOwqL0R6DHz9SjLmsg@mail.gmail.com>
In-Reply-To: <CABm2gDp1r78OtM=MfHqvV17-6N=nCG+hFOwqL0R6DHz9SjLmsg@mail.gmail.com>
From: =?UTF-8?Q?Cl=C3=A9ment_Elbaz?= <clem.ds@gmail.com>
Date: Mon, 05 Oct 2015 12:08:27 +0000
Message-ID: <CAP63atY+yH5BinWYAyxkqER5wA9Lj6pFC0LritSDLcDuBVbXrg@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>, 
	Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=001a11376a7287e85105215a5f0e
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

--001a11376a7287e85105215a5f0e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It will get correct results about :
- the existence every block
- the existence of every transaction

It will get incorrect results :
- about the *nature* of some transactions
- and therefore, about the balances of some wallets.

I fully agree with Mike here.

Le lun. 5 oct. 2015 =C3=A0 14:04, Jorge Tim=C3=B3n <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

>
> On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Well, let's agree to disagree on these two things:
> >
> > - I define "working" for a full node as verifying everything; if a node
> starts skipping bits then I'd say it's not really "working" according to
> its original design goals
>
> But assuming the hashrate majority has upgraded (and we're using 95% as
> the miner upgrade confirmation threshold to start activation, so that
> assumption seems pretty safe), a non-upgraded full node and an upgraded
> full will converge on what they see: "the most-work valid chain" will be
> the same for both. A non-upgraded full node wallet waiting for several
> confirmations (for example, 6 confirmations) will be just as safe as an
> upgraded one. In that sense, it keeps working. On top of that, nodes (of
> any kind) can use unknown block version numbers to notify the user or eve=
n
> stop working (the same notification mechanism you would use with hardfork=
s).
>
> I agree that hardforks are necessary and we should deploy a hardfork asap
> to show the world they are indeed possible (bip99 proposes a likely
> uncontroversial one), but I still believe that is clear that softfork
> deployment is preferrable in many cases like this one.
>
> Are you going to produce a bip65 hardfork alternative to try to convince
> people of its advantages over bip65 (it is not clear to me how you includ=
e
> a new script operand via hardfork)?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">It will get correct results about :<div>- the existence ev=
ery block</div><div>- the existence of every transaction</div><div><br></di=
v><div>It will get incorrect results :</div><div>- about the <i>nature</i> =
of some transactions</div><div>- and therefore, about the balances of some =
wallets.</div><div><br></div><div>I fully agree with Mike here.</div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0lun. 5 oct. 2015 =
=C3=A0=C2=A014:04, Jorge Tim=C3=B3n &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=
=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr"><br>
On Oct 5, 2015 1:28 PM, &quot;Mike Hearn via bitcoin-dev&quot; &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Well, let&#39;s agree to disagree on these two things:<br>
&gt;<br>
&gt; - I define &quot;working&quot; for a full node as verifying everything=
; if a node starts skipping bits then I&#39;d say it&#39;s not really &quot=
;working&quot; according to its original design goals</p>
<p dir=3D"ltr">But assuming the hashrate majority has upgraded (and we&#39;=
re using 95% as the miner upgrade confirmation threshold to start activatio=
n, so that assumption seems pretty safe), a non-upgraded full node and an u=
pgraded full will converge on what they see: &quot;the most-work valid chai=
n&quot; will be the same for both. A non-upgraded full node wallet waiting =
for several confirmations (for example, 6 confirmations) will be just as sa=
fe as an upgraded one. In that sense, it keeps working. On top of that, nod=
es (of any kind) can use unknown block version numbers to notify the user o=
r even stop working (the same notification mechanism you would use with har=
dforks).</p>
<p dir=3D"ltr">I agree that hardforks are necessary and we should deploy a =
hardfork asap to show the world they are indeed possible (bip99 proposes a =
likely uncontroversial one), but I still believe that is clear that softfor=
k deployment is preferrable in many cases like this one.</p>
<p dir=3D"ltr">Are you going to produce a bip65 hardfork alternative to try=
 to convince people of its advantages over bip65 (it is not clear to me how=
 you include a new script operand via hardfork)?<br>
</p>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--001a11376a7287e85105215a5f0e--