Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B89B256 for ; Wed, 16 Nov 2016 13:29:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 95574285 for ; Wed, 16 Nov 2016 13:29:42 +0000 (UTC) Received: by mail-oi0-f49.google.com with SMTP id 128so59899573oih.0 for ; Wed, 16 Nov 2016 05:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7owFq+sA4MW371X6ROKiO7a2Y58dG2wVtjpjfC+iZNk=; b=kzjk5cVuClWnJSHFL4L4Qf6HH8JZFNEwNECRsgTOXW6byQxpUJ2Txu4bgpwg/l5sgk sWNAsaG1TOpX2sOP5Y2anoS+EH4oCu2yqDBiIQDJK5zGwkldqEQVleqtavNDaCXhC6vb RjdgB91GsBwEr0NgKa+Kn3mtPnPlIjhF+eUhXgaJUo4zhx88S9RO3Bu6EpWdi9so40OC K3aPEqZHRJpDPfFl/jGvLEQaj276iGxMqEKjQJgZT0pUGM3OHQUmIQwMxWP/7+krFd3C XoR3Jm90TJuihQN2dJRMFYqHHhfRY8X9cUFz5WY0VhqlT7jyISoVYeO6yr/b2G0/IKIq Vpyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7owFq+sA4MW371X6ROKiO7a2Y58dG2wVtjpjfC+iZNk=; b=jTgfLtuiKLsI/iQKopuq21kCMmmOhviweOaGyY0ke8yRDOwpDarP+wkSObNiLrfelV P9GjwKSBySMrKO3+BfhKdH/Y4taOJnWiATqzDsFsmlOM3xBnSg1J2P4mlb1b0v8URPLl HrfkTQocCxAVTyhdkfcFoTuWEXdC9yih+dE3t80+Gt5g01zo7ha4WKDwPZS9/kObUjRu poNQwbLPM1FNy2OnXrpqx9SD7p67E/uWpJJWAFPmgVairbveT33VDaEcQk3Yjtbrb+T0 GKiSch2gysnp7TREFTy0HbuV3sKPiZRR/ehaxlAArGA08b7ZoEidyETflSFgxwTq+vgt G4mg== X-Gm-Message-State: ABUngvfKow7ET8mMfX3jxjVq7anoX9oghFWOSKyLXNcnZUsWmKwyQcRgMEyyrXvKTKr2XRQ4Y9KfQQ81tWunzg== X-Received: by 10.202.89.9 with SMTP id n9mr2227937oib.141.1479302981897; Wed, 16 Nov 2016 05:29:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.106.9 with HTTP; Wed, 16 Nov 2016 05:29:41 -0800 (PST) In-Reply-To: <33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org> References: <33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org> From: Jameson Lopp Date: Wed, 16 Nov 2016 08:29:41 -0500 Message-ID: To: Eric Voskuil , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a113d632ec052cb05416b1022 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 13:29:43 -0000 --001a113d632ec052cb05416b1022 Content-Type: text/plain; charset=UTF-8 Since "buried deployments" are specifically in reference to historical consensus changes, I think the question is more one of human consensus than machine consensus. Is there any disagreement amongst Bitcoin users that BIP34 activated at block 227931, BIP65 activated at block 388381, and BIP66 activated at block 363725? Somehow I doubt it. It seems to me that this change is merely cementing into place a few attributes of the blockchain's history that are not in dispute. - Jameson On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Actually this does nothing to provide justification for this 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 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 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 > >> 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 > >> > >> > >> _______________________________________________ > >> 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 > --001a113d632ec052cb05416b1022 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since "buried deployments" = are specifically in reference to historical consensus changes, I think the = question is more one of human consensus than machine consensus. Is there an= y disagreement amongst Bitcoin users that BIP34 activated at block 227931, BIP65 activated at block 388381, and BIP66 activated at block 363725? Some= how I doubt it.

It seems to me that this change is merely= cementing into place a few attributes of the blockchain's history that= are not in dispute.

- Jameson

On Tue, Nov 15, 2016= at 5:42 PM, Eric Voskuil via bitcoin-dev <bitcoin-dev= @lists.linuxfoundation.org> wrote:
Actually this does nothing to provide justification for this consen= sus rule change. It is just an attempt to deflect criticism from the fact t= hat 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=
> 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-d= ev@lists.linuxfoundation.org> wrote:
>> NACK
>>
>> Horrible precedent (hardcoding rule changes based on the assumptio= n that
>> large forks indicate a catastrophic failure), extremely poor proce= ss
>> (already shipped, now the discussion), and not even a material per= formance
>> optimization (the checks are avoidable once activated until a suff= iciently
>> deep reorg deactivates them).
>>
>> e
>>
>> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
>> <bitco= in-dev@lists.linuxfoundation.org> wrote:
>>
>> Hi,
>>
>> Recently Bitcoin Core merged a simplification to the consensus rul= es
>> surrounding deployment of BIPs 34, 66, and 65
>> (https://github.com/bitcoin/bitcoin/pull/8= 391), and though the change is a
>> minor one, I thought it was worth documenting the rationale in a B= IP for
>> posterity.
>>
>> Here's the abstract:
>>
>> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via m= iner
>> signaling in block version numbers. Now that the chain has long si= nce 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.<= br> >>
>> The full draft can be found here:
>>
>> ht= tps://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried= -deployments.mediawiki
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@lists.linuxfoundation.org
>> https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@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

--001a113d632ec052cb05416b1022--