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 4961F723 for ; Tue, 15 Nov 2016 17:46:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 94F471AC for ; Tue, 15 Nov 2016 17:46:07 +0000 (UTC) Received: by mail-wm0-f51.google.com with SMTP id a197so182095784wmd.0 for ; Tue, 15 Nov 2016 09:46:07 -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=7vaA0jra8by0adelE4i/IQsPwtIuz2h+JlpMBcWWgxk=; b=Bah/WE9L5ZyAW2bjcBYs3DGt1oNBP3D0jWGuPLVxXfaEpZNjVYvNTl4bYf2khqw8Ja FtlbVH+JhMrOfkBz3RX4XtaI7vbhXFg2CD4Dybxp96nQYBCKVtyEyVrMPZzHZHaVPDTv 2LXjT+JwdvcrnCdKjNZUKcA4ZTU4t4D/ValDSYSX8MLKDGWIn+Jc+zPIVO8cmnRC0Qz6 R2OOwKy9WxI8EH5yauOmWNKKs+Ur0fJ2OCdhm1AiISkuzalb8ud/7awfIzGgETtu50F1 IkWh3lFuxXrqoA4L73qAJ2PNpb+HHehQxwYvNZO7d1j1/ZNlTqrIw+UpowDJMSeVpuk1 Cqfg== 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=7vaA0jra8by0adelE4i/IQsPwtIuz2h+JlpMBcWWgxk=; b=Vik1IBZ3XA3aF5amTO7xV1apd3mXe5OsiQIWPbz4bv+3DCA14JVBj+HfuHn57Uxg0W TAT/vzZMufD1drmHkBUVvayodgHbHsNFmtX46y61zLBvmp2QQnOr3K55xXGueXFIn1sK R6DEJBciEbJUj2dc0duFOdA4QX+KOXy+N9+nbq08xUPp546eiy8T5AB5XotEB6bEwaQ5 nC09NllAWejMbx3VlK41ERHTyE/J5vPC8MFLHTxbvF4zVdE2RHZu0hGL2vAcUpDL1ntA pxsvSZjJRAls7Qndc1S2u93Wju2kcjdgvBdQVTapM2C7QXF9f1/x5meBMaS8PwAUVy+H a/ZA== X-Gm-Message-State: ABUngveTXFzfQepxF2SJe2TXXf3ttg03ZCAK0aHnR5H0btFgW+pud3dKwYwzQHDsOHXZmbI/5M3UWDU1dwEk+Q== X-Received: by 10.194.57.9 with SMTP id e9mr23812237wjq.116.1479231965844; Tue, 15 Nov 2016 09:46:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.195.13.201 with HTTP; Tue, 15 Nov 2016 09:45:45 -0800 (PST) In-Reply-To: References: From: Btc Drak Date: Tue, 15 Nov 2016 17:45:45 +0000 Message-ID: To: Eric Voskuil , Bitcoin Protocol Discussion Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, 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 X-Mailman-Approved-At: Tue, 15 Nov 2016 18:01:31 +0000 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 17:46:08 -0000 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 >