From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6C86EC2B for ; Tue, 15 Nov 2016 14:42:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com [209.85.220.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5E70E370 for ; Tue, 15 Nov 2016 14:42:52 +0000 (UTC) Received: by mail-qk0-f178.google.com with SMTP id x190so137228247qkb.0 for ; Tue, 15 Nov 2016 06:42:52 -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=vqGxtEQezwE/ECbQfyg4bh0S88H93yqG+Fb6TDRv31I=; b=0edg7UWfcRIeBRE2wlyLYz8jNktj9BBFXt6IDKTXTlmaE4oDxO4cZ9ze1muXC+lvhI rwO/uqUdmUHZYkM7WHh2UuMfBcm4dcC8XP3M+Us/Tw2VDYez6MBTeAJ18WvNd2dab685 bhhqegpXHolZVxqtBDD7htucMSSOaVTvuPIysId3JRdMM+nS52mYMHMIcT/bHXN89lDH sartUKztLEBeAtJfcszJXcyoSuFIN/hWn9XFy5zFWy1hjpF1UkZLM0cbyZdFPgCE4ews 02PLB01nbB+E3h5b1TQ3y+7w598+XxHDbIFtfvMzJ8e5u7C6MkLXK3c0CCqMOTKAMQ0n Dvig== 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=vqGxtEQezwE/ECbQfyg4bh0S88H93yqG+Fb6TDRv31I=; b=gyoyXrLy9xsFfA1Lh3UoaF0TSxs89FeFE+apxFjGhO1KIQRAipB6Hv0NPyov5AdY8j /Rc4E8sO5M5D0qu9K+M5JXj+uFyg6zyPZLZzFWO2zGnehNCzmkZE5YDxVAgLwsy5BPSu 91R2r/m8TMWTKalSWawBW9MSOTH9rjKp2ZXXe+lgS6muT2/jQJuxrE++tFDsdQR04TRG 7ypTDiDb91+jqBwyxADciRogLiNML8aRQyIpuqrkwIME6YvkTkfK4fnVYfPyhGe6OmkM 4m6SxHHN9y7DIFvZpusJDJODJ0E8cT0GVY37IA4fXvceUvx5BmL9qSm9UkbI/oWW1+sF ZMcA== X-Gm-Message-State: ABUngveq3mIqp2ZXkqiWzP6SiFj9v58gi0RJXNvFiXWSPSvity1ko6Uk4uXN5xlfkS/9a8Kk9UhHLSZwlujZJg== X-Received: by 10.55.5.134 with SMTP id 128mr24972466qkf.261.1479220971317; Tue, 15 Nov 2016 06:42:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.88.133 with HTTP; Tue, 15 Nov 2016 06:42:50 -0800 (PST) In-Reply-To: References: From: Suhas Daftuar Date: Tue, 15 Nov 2016 09:42:50 -0500 Message-ID: To: Eric Voskuil Content-Type: multipart/alternative; boundary=001a114c819e8a30db054157f86b X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Tue, 15 Nov 2016 14:42:53 -0000 --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 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
Just want to clarify two points:

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

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

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

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>
e

On Nov 14, 2016, = at 10:17 AM, Suhas Daftuar via bitcoin-dev <bitcoin-dev@lists.linux= foundation.org> wrote:

<= div dir=3D"ltr">Hi,

Recently Bitcoin Core merged a simpl= ification 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 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.

The full draft can be fou= nd here:=C2=A0

_______= ________________________________________
bitcoin-dev m= ailing list
bitcoin-dev@lists.linuxfoundation.org<= /span>
https://lists.linuxfoundation.org/ma= ilman/listinfo/bitcoin-dev

--001a114c819e8a30db054157f86b--