MIME-Version: 1.0
In-Reply-To: <CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
	<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Tue, 15 Nov 2016 09:42:50 -0500
Message-ID: <CAFp6fsEqqttOKq1oyUEuwnxVxxk=u3ZejhNMX51SpL0mWGyWNQ@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary=001a114c819e8a30db054157f86b
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
Precedence: list

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

Just want to clarify two points:

This change has not yet appeared in any released software (but I assume it
will be in the next release, 0.14.0).

I agree that the performance optimization is not the point of this change;
I can modify the BIP draft to de-emphasize that further (perhaps remove
mention of it entirely).

On Mon, Nov 14, 2016 at 1:47 PM, Eric Voskuil <eric@voskuil.org> wrote:

> NACK
>
> Horrible precedent (hardcoding rule changes based on the assumption that
> large forks indicate a catastrophic failure), extremely poor process
> (already shipped, now the discussion), and not even a material performance
> optimization (the checks are avoidable once activated until a sufficiently
> deep reorg deactivates them).
>
> e
>
> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi,
>
> Recently Bitcoin Core merged a simplification to the consensus rules
> surrounding deployment of BIPs 34, 66, and 65 (https://github.com/bitcoin/
> bitcoin/pull/8391), and though the change is a minor one, I thought it
> was worth documenting the rationale in a BIP for posterity.
>
> Here's the abstract:
>
> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner
> signaling in block version numbers. Now that the chain has long since
> passed the blocks at which those consensus rules have triggered, we can (as
> a simplification and optimization) replace the trigger mechanism by caching
> the block heights at which those consensus rules became enforced.
>
> The full draft can be found here:
>
> https://github.com/sdaftuar/bips/blob/buried-deployments/
> bip-buried-deployments.mediawiki
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div>Just want to clarify two points:</div><div><br></div>=
<div>This change has not yet appeared in any released software (but I assum=
e it will be in the next release, 0.14.0).<br></div><div><br></div><div>I a=
gree that the performance optimization is not the point of this change; I c=
an modify the BIP draft to de-emphasize that further (perhaps remove mentio=
n of it entirely).</div></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Mon, Nov 14, 2016 at 1:47 PM, Eric Voskuil <span dir=3D"ltr=
">&lt;<a href=3D"mailto:eric@voskuil.org" target=3D"_blank">eric@voskuil.or=
g</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"=
><div></div><div>NACK</div><div><br></div><div>Horrible precedent (hardcodi=
ng rule changes based on the assumption that large forks indicate a catastr=
ophic failure), extremely poor process (already shipped, now the discussion=
), and not even a material performance optimization (the checks are avoidab=
le once activated until a sufficiently deep reorg deactivates them).</div><=
div><br></div><div>e</div><div><div class=3D"h5"><div><br>On Nov 14, 2016, =
at 10:17 AM, Suhas Daftuar via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linux=
foundation.org</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><=
div dir=3D"ltr">Hi,<div><br></div><div>Recently Bitcoin Core merged a simpl=
ification to the consensus rules surrounding deployment of BIPs 34, 66, and=
 65 (<a href=3D"https://github.com/bitcoin/bitcoin/pull/8391" target=3D"_bl=
ank">https://github.com/bitcoin/<wbr>bitcoin/pull/8391</a>), and though the=
 change is a minor one, I thought it was worth documenting the rationale in=
 a BIP for posterity.</div><div><br></div><div>Here&#39;s the abstract:</di=
v><div><br></div><blockquote style=3D"margin:0px 0px 0px 40px;border:none;p=
adding:0px"><div><div>Prior soft forks (BIP 34, BIP 65, and BIP 66) were ac=
tivated via miner signaling in block version numbers. Now that the chain ha=
s long since passed the blocks at which those consensus rules have triggere=
d, we can (as a simplification and optimization) replace the trigger mechan=
ism by caching the block heights at which those consensus rules became enfo=
rced.</div></div><div><br></div></blockquote><div>The full draft can be fou=
nd here:=C2=A0</div><div><br></div><div><a href=3D"https://github.com/sdaft=
uar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki" target=
=3D"_blank">https://github.com/sdaftuar/<wbr>bips/blob/buried-deployments/<=
wbr>bip-buried-deployments.<wbr>mediawiki</a></div></div>
</div></blockquote></div></div><blockquote type=3D"cite"><div><span>_______=
_______________________<wbr>_________________</span><br><span>bitcoin-dev m=
ailing list</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><=
/span><br><span><a href=3D"https://lists.linuxfoundation.org/mailman/listin=
fo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/ma=
ilman/listinfo/bitcoin-<wbr>dev</a></span><br></div></blockquote></div></bl=
ockquote></div><br></div>

--001a114c819e8a30db054157f86b--