MIME-Version: 1.0
In-Reply-To: <CA+w+GKRjURkV40iG=6RLhFyQ-t2G_YAinKk7Os_8zK4+hyYJaw@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>
	<CABm2gDp1r78OtM=MfHqvV17-6N=nCG+hFOwqL0R6DHz9SjLmsg@mail.gmail.com>
	<CA+w+GKS-AZGBSwuN1dgEs6wa-R=jHE0fmfmQ0TL9Cw9b6L71UQ@mail.gmail.com>
	<CABm2gDpgpRg9U5ToNM98pQgz8VRwT8o817zrpJgOj06PwySk_Q@mail.gmail.com>
	<CA+w+GKRjURkV40iG=6RLhFyQ-t2G_YAinKk7Os_8zK4+hyYJaw@mail.gmail.com>
Date: Wed, 7 Oct 2015 09:13:23 +0300
Message-ID: <CAAmoQf3o5OLhtcsh4OZ_cp52vf__L7oxow+7CFx7WKQoEHCpFw@mail.gmail.com>
From: Micha Bailey <michabailey@gmail.com>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=001a113eba38de733f05217da4d2
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

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

On Monday, October 5, 2015, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> As Greg explained to you repeatedly, a softfork won't cause a
>> non-upgraded full node to start accepting blocks that create more
>> subsidy than is valid.
>>
>
> It was an example. Adam Back's extension blocks proposal would, in fact,
> allow for a soft forking change that creates more subsidy than is valid (or
> does anything else) by hiding one block inside another.
>

Maybe I'm missing something, but wouldn't this turn into a hard fork the
moment you try to spend an output created in one of these extension blocks?
So sure, the block that contains the extension would be considered valid,
but unupgraded validators will not update the UTXO set accordingly, meaning
that those new TXOs can't be spent because, according to their rules, they
don't exist.

>
>

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

<br><br>On Monday, October 5, 2015, Mike Hearn via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
As Greg explained to you repeatedly, a softfork won&#39;t cause a<br>
non-upgraded full node to start accepting blocks that create more<br>
subsidy than is valid.<br></blockquote><div><br></div><div>It was an exampl=
e. Adam Back&#39;s extension blocks proposal would, in fact, allow for a so=
ft forking change that creates more subsidy than is valid (or does anything=
 else) by hiding one block inside another.</div></div></div></div></blockqu=
ote><div><br></div><div>Maybe I&#39;m missing something, but wouldn&#39;t t=
his turn into a hard fork the moment you try to spend an output created in =
one of these extension blocks? So sure, the block that contains the extensi=
on would be considered valid, but unupgraded validators will not update the=
 UTXO set accordingly, meaning that those new TXOs can&#39;t be spent becau=
se, according to their rules, they don&#39;t exist.</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><br></div></div></div>
</blockquote>

--001a113eba38de733f05217da4d2--