MIME-Version: 1.0
In-Reply-To: <CA+w+GKTkos5gwZmN_1c7wUFmJgZMJGzZbaZeWO=Rwt3Ta3Zbzw@mail.gmail.com>
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>
Date: Mon, 5 Oct 2015 14:04:12 +0200
Message-ID: <CABm2gDp1r78OtM=MfHqvV17-6N=nCG+hFOwqL0R6DHz9SjLmsg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=001a1130cc42d52dfd05215a4f42
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

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

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 even
stop working (the same notification mechanism you would use with hardforks).

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 include
a new script operand via hardfork)?

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

<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">bitcoin-dev@lists.linuxfo=
undation.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>

--001a1130cc42d52dfd05215a4f42--