Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C7BEE723 for ; 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 ; Wed, 16 Nov 2016 13:58:59 +0000 (UTC) Received: by mail-pg0-f46.google.com with SMTP id f188so79304965pgc.3 for ; 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 X-Mailer: iPhone Mail (14B100) In-Reply-To: Date: Wed, 16 Nov 2016 05:58:57 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org> To: Jameson Lopp 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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 >> > 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 >> >> 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
This sort of statement repr= esents one consequence of the aforementioned bad precedent.

Are checkpoints good now? Are hard forks okay now?

What is the maximum depth of a reorg allowed by this non-machine co= nsensus?

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

Why are there activation heights defined by this hard f= ork if it's not possible to reorg back to them?

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).

e

On Nov 16, 2016, at 5:29 AM, Jameson Lopp <jameson.lopp@gmail.com> wrote:
<= /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 227931, BIP65 activated at block 388381, and BIP66 activated a= t block 363725? Somehow I doubt it.

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.

- Jameson
<= /span>

On Tue= , Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev &l= t;bitcoin-dev@lists.linuxfoundation.org> wrote:
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.

e

> 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<= br> > 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<= br> > 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-de= v@lists.linuxfoundation.org> wrote:
>> NACK
>>
>> Horrible precedent (hardcoding rule changes based on the assumption= that
>> large forks indicate a catastrophic failure), extremely poor proces= s
>> (already shipped, now the discussion), and not even a material perf= ormance
>> optimization (the checks are avoidable once activated until a suffi= ciently
>> deep reorg deactivates them).
>>
>> e
>>
>> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
>> <bitcoi= n-dev@lists.linuxfoundation.org> wrote:
>>
>> Hi,
>>
>> Recently Bitcoin Core merged a simplification to the consensus rule= s
>> surrounding deployment of BIPs 34, 66, and 65
>> (https://github.com/bitcoin/bitcoin/pull/839= 1), and though the change is a
>> minor one, I thought it was worth documenting the rationale in a BI= P for
>> posterity.
>>
>> Here's the abstract:
>>
>> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via mi= ner
>> signaling in block version numbers. Now that the chain has long sin= ce passed
>> the blocks at which those consensus rules have triggered, we can (a= s a
>> simplification and optimization) replace the trigger mechanism by c= aching
>> the block heights at which those consensus rules became enforced. >>
>> The full draft can be found here:
>>
>> http= s://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-de= ployments.mediawiki
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-de= v@lists.linuxfoundation.org
>> https://lists.linuxfoundation.<= wbr>org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-de= v@lists.linuxfoundation.org
>> https://lists.linuxfoundation.<= wbr>org/mailman/listinfo/bitcoin-dev
>>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.<= wbr>linuxfoundation.org
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev

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