path: root/35/ecbf759681938e1c29c8d97bcde218fb2d0994

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C7BEE723
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Nov 2016 13:59:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com [74.125.83.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86BA82F1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Nov 2016 13:58:59 +0000 (UTC)
Received: by mail-pg0-f46.google.com with SMTP id f188so79304965pgc.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Nov 2016 05:58:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=nVMWtE9k5B4DagyIW2uM9o8siiAxHcBXu1/fF6YYLDQ=;
	b=mSKDsa4wEumOLcFQfYMyOfajyKqDyFSoc2ge/c3pXl6/KNOhXVPvrS8qDzZi59oeTV
	UYPL8Lzt0jqPfPpRLc3354aCJAV4wBU4FTzjLHKJj8bkBNUezgXZebdhjySlwv0+Qvfm
	hn5yFbdHSjIdFBjHmkEGTtoQ06GQHXrMtU0urcnlVnFGnYHWQTtz3OzEHNtsSgrmL5L/
	NNzmfIB28a3YQiuUeSsJaNNt70MZqwNzrI+75q3jxazCqzwV3dVmCYGtBS0zt+dblbuW
	cND3s/TLKe1xhLSZ02taoWyzckPkZUX+dggpdDVBEBfhTHqDdMfcdrsUPuXLHxIGxsCf
	5RhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=nVMWtE9k5B4DagyIW2uM9o8siiAxHcBXu1/fF6YYLDQ=;
	b=cTnqMWyk0gQFgYuuA2zomQeHb5BDTsS9jvAlLmiVjBbSpSLRQ1SmAFMndsXGVmihAu
	IxpJphZYozGne+6Ikvvg2oQeLGC3aT+0/u4p6POR4b0cAIKkxxnjfEzN3ruMnXb9f5UL
	DW2l2CcZU5rJq+9Q+sNnMxwyNUXWiz5Jkwar5S1W5z5VXs3mXuYuzEhKpZ1JC23S9CT+
	cwDY7QKcn96vnyz+mb2TauQiHapBJn2X8NNLVF/noedR7jT1R+3mPiqkYpMtdhoCxael
	aU0HYu6Jv0VbAftzfZ1CZIivxpKOAWEipmxoTxANk38Awf1DbLoR5w8jS8bjShoMibnW
	YcUA==
X-Gm-Message-State: ABUngvf+G+sAV67nQArhrgeaVO5+WA7sEixW1At+t7Nq6m17G8jykfIkCPqwGVbzj7DUKw==
X-Received: by 10.98.26.88 with SMTP id a85mr4674156pfa.57.1479304739108;
	Wed, 16 Nov 2016 05:58:59 -0800 (PST)
Received: from ?IPv6:2601:600:9000:d69e:b065:bf91:be39:5ca3?
	([2601:600:9000:d69e:b065:bf91:be39:5ca3])
	by smtp.gmail.com with ESMTPSA id
	72sm24946524pfw.37.2016.11.16.05.58.57
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 16 Nov 2016 05:58:58 -0800 (PST)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-7692ED84-D94E-405D-85E5-251F5949BBB1
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14B100)
In-Reply-To: <CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
Date: Wed, 16 Nov 2016 05:58:57 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
	<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
	<CADJgMzunxU2-7Z_ZPafNY4BPRu0x9oeh6v2dg0nUYqxJbXeGYA@mail.gmail.com>
	<33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org>
	<CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
To: Jameson Lopp <jameson.lopp@gmail.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HTML_MESSAGE,MIME_QP_LONG_LINE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 16 Nov 2016 14:00:47 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2016 13:59:00 -0000


--Apple-Mail-7692ED84-D94E-405D-85E5-251F5949BBB1
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

This sort of statement represents one consequence of the aforementioned bad p=
recedent.

Are checkpoints good now? Are hard forks okay now?

What is the maximum depth of a reorg allowed by this non-machine consensus?

Shouldn't we just define a max depth so that all cruft deeper than that can j=
ust be discarded on a regular basis?

Why are there activation heights defined by this hard fork if it's not possi=
ble to reorg back to them?

The "BIP" is neither a Proposal (it's been decided, just documenting for pos=
terity), nor an Improvement (there is no actual benefit, just some tidying u=
p in the notoriously obtuse satoshi code base), nor Bitcoin (a hard fork def=
ines an alt coin, so from Aug 4 forward it has been CoreCoin).

e

> On Nov 16, 2016, at 5:29 AM, Jameson Lopp <jameson.lopp@gmail.com> wrote:
>=20
> Since "buried deployments" are specifically in reference to historical con=
sensus changes, I think the question is more one of human consensus than mac=
hine consensus. Is there any disagreement amongst Bitcoin users that BIP34 a=
ctivated at block 227931, BIP65 activated at block 388381, and BIP66 activat=
ed at block 363725? Somehow I doubt it.
>=20
> It seems to me that this change is merely cementing into place a few attri=
butes of the blockchain's history that are not in dispute.
>=20
> - Jameson
>=20
>> On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org> wrote:
>> Actually this does nothing to provide justification for this consensus ru=
le change. It is just an attempt to deflect criticism from the fact that it i=
s such a change.
>>=20
>> e
>>=20
>> > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak@gmail.com> wrote:
>> >
>> > I think this is already covered in the BIP text:-
>> >
>> > "As of November 2016, the most recent of these changes (BIP 65,
>> > enforced since December 2015) has nearly 50,000 blocks built on top of
>> > it. The occurrence of such a reorg that would cause the activating
>> > block to be disconnected would raise fundamental concerns about the
>> > security assumptions of Bitcoin, a far bigger issue than any
>> > non-backwards compatible change.
>> >
>> > So while this proposal could theoretically result in a consensus
>> > split, it is extremely unlikely, and in particular any such
>> > circumstances would be sufficiently damaging to the Bitcoin network to
>> > dwarf any concerns about the effects of this proposed change."
>> >
>> >
>> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
>> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >> NACK
>> >>
>> >> Horrible precedent (hardcoding rule changes based on the assumption th=
at
>> >> large forks indicate a catastrophic failure), extremely poor process
>> >> (already shipped, now the discussion), and not even a material perform=
ance
>> >> optimization (the checks are avoidable once activated until a sufficie=
ntly
>> >> 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 i=
s a
>> >> minor one, I thought it was worth documenting the rationale in a BIP f=
or
>> >> 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 p=
assed
>> >> the blocks at which those consensus rules have triggered, we can (as a=

>> >> simplification and optimization) replace the trigger mechanism by cach=
ing
>> >> 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-de=
ployments.mediawiki
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20

--Apple-Mail-7692ED84-D94E-405D-85E5-251F5949BBB1
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div>This sort of statement repr=
esents one consequence of the aforementioned bad precedent.</div><div><br></=
div><div>Are checkpoints good now? Are hard forks okay now?</div><div><br></=
div><div>What is the maximum depth of a reorg allowed by this non-machine co=
nsensus?</div><div><br></div><div>Shouldn't we just define a max depth so th=
at all cruft deeper than that can just be discarded on a regular basis?</div=
><div><br></div><div>Why are there activation heights defined by this hard f=
ork if it's not possible to reorg back to them?</div><div><br></div><div>The=
 "BIP" is neither a Proposal (it's been decided, just documenting for poster=
ity), nor an Improvement (there is no actual benefit, just some tidying up i=
n the notoriously obtuse satoshi code base), nor Bitcoin (a hard fork define=
s an alt coin, so from Aug 4 forward it has been CoreCoin).</div><div><br></=
div><div>e</div><div><br>On Nov 16, 2016, at 5:29 AM, Jameson Lopp &lt;<a hr=
ef=3D"mailto:jameson.lopp@gmail.com">jameson.lopp@gmail.com</a>&gt; wrote:<b=
r><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div><div><div><=
/div>Since "buried deployments" are specifically in reference to historical c=
onsensus changes, I think the question is more one of human consensus than m=
achine consensus. Is there any disagreement amongst Bitcoin users that BIP34=
 activated at block <span class=3D"gmail-blob-code-inner"><span class=3D"gma=
il-pl-c1">227931,</span></span> BIP65 activated at block <span class=3D"gmai=
l-blob-code-inner"><span class=3D"gmail-pl-c1">388381, and BIP66 activated a=
t block </span></span><span class=3D"gmail-blob-code-inner"><span class=3D"g=
mail-pl-c1">363725? Somehow I doubt it.<br><br></span></span></div><span cla=
ss=3D"gmail-blob-code-inner"><span class=3D"gmail-pl-c1">It seems to me that=
 this change is merely cementing into place a few attributes of the blockcha=
in's history that are not in dispute.<br><br></span></span></div><span class=
=3D"gmail-blob-code-inner"><span class=3D"gmail-pl-c1">- Jameson<br></span><=
/span></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue=
, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">Actually this does nothing to provide justification for thi=
s consensus rule change. It is just an attempt to deflect criticism from the=
 fact that it is such a change.<br>
<br>
e<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; On Nov 15, 2016, at 9:45 AM, Btc Drak &lt;<a href=3D"mailto:btcdrak@gma=
il.com">btcdrak@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; I think this is already covered in the BIP text:-<br>
&gt;<br>
&gt; "As of November 2016, the most recent of these changes (BIP 65,<br>
&gt; enforced since December 2015) has nearly 50,000 blocks built on top of<=
br>
&gt; it. The occurrence of such a reorg that would cause the activating<br>
&gt; block to be disconnected would raise fundamental concerns about the<br>=

&gt; security assumptions of Bitcoin, a far bigger issue than any<br>
&gt; non-backwards compatible change.<br>
&gt;<br>
&gt; So while this proposal could theoretically result in a consensus<br>
&gt; split, it is extremely unlikely, and in particular any such<br>
&gt; circumstances would be sufficiently damaging to the Bitcoin network to<=
br>
&gt; dwarf any concerns about the effects of this proposed change."<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; NACK<br>
&gt;&gt;<br>
&gt;&gt; Horrible precedent (hardcoding rule changes based on the assumption=
 that<br>
&gt;&gt; large forks indicate a catastrophic failure), extremely poor proces=
s<br>
&gt;&gt; (already shipped, now the discussion), and not even a material perf=
ormance<br>
&gt;&gt; optimization (the checks are avoidable once activated until a suffi=
ciently<br>
&gt;&gt; deep reorg deactivates them).<br>
&gt;&gt;<br>
&gt;&gt; e<br>
&gt;&gt;<br>
&gt;&gt; On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev<br>
&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoi=
n-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; Recently Bitcoin Core merged a simplification to the consensus rule=
s<br>
&gt;&gt; surrounding deployment of BIPs 34, 66, and 65<br>
&gt;&gt; (<a href=3D"https://github.com/bitcoin/bitcoin/pull/8391" rel=3D"no=
referrer" target=3D"_blank">https://github.com/bitcoin/<wbr>bitcoin/pull/839=
1</a>), and though the change is a<br>
&gt;&gt; minor one, I thought it was worth documenting the rationale in a BI=
P for<br>
&gt;&gt; posterity.<br>
&gt;&gt;<br>
&gt;&gt; Here's the abstract:<br>
&gt;&gt;<br>
&gt;&gt; Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via mi=
ner<br>
&gt;&gt; signaling in block version numbers. Now that the chain has long sin=
ce passed<br>
&gt;&gt; the blocks at which those consensus rules have triggered, we can (a=
s a<br>
&gt;&gt; simplification and optimization) replace the trigger mechanism by c=
aching<br>
&gt;&gt; the block heights at which those consensus rules became enforced.<b=
r>
&gt;&gt;<br>
&gt;&gt; The full draft can be found here:<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"https://github.com/sdaftuar/bips/blob/buried-deployments=
/bip-buried-deployments.mediawiki" rel=3D"noreferrer" target=3D"_blank">http=
s://github.com/sdaftuar/<wbr>bips/blob/buried-deployments/<wbr>bip-buried-de=
ployments.<wbr>mediawiki</a><br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitco=
in-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<=
wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitco=
in-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<=
wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;&gt;<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<=
wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/m=
ailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote></body></html>=

--Apple-Mail-7692ED84-D94E-405D-85E5-251F5949BBB1--