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 0F277256 for ; Tue, 15 Nov 2016 22:42:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com [209.85.192.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8133F249 for ; Tue, 15 Nov 2016 22:42:08 +0000 (UTC) Received: by mail-pf0-f180.google.com with SMTP id d2so38463624pfd.0 for ; Tue, 15 Nov 2016 14:42:08 -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=5cE1l1C44j3wTobNCoCNXHhyKPNQfuZtHawCJHyNjKg=; b=mJuL+rqi86g1SsaaubBonOe+sg9Vx4dmiXvURIi1xlV+f8PuEW3IbOlZ3o8ipomQt+ 3d1w0nXUFEg0LYPZWtCtf8XIYiOBr5Ug37qFYrKp8LL7S9+rSnbHG8i61fChBPLTdb9V seQCR+Hk7XMtfhQA3jEUmNHNjUqLtqeW7tVIONHsWhKDWa7epUm541E3HxXAmlqkaib+ v8nC2Hs/XO9DqiMFjrGHOa9RFLLG6OLnPfLA1xU/OkhYys802aSmJBRyIz0bXrLC5hlL Af04djg1tgvzX2gT/6TPFp92F/WHorJdc79A7t8qWh7j/caWGqjgFUqckHdNYQc0EvkU ySZw== 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=5cE1l1C44j3wTobNCoCNXHhyKPNQfuZtHawCJHyNjKg=; b=R0H/fzjxjV6+miDkC7OpjJPHpjgUueClX/P1f+toGR8cOCIWXh142wNtTrsgn/p6Gn wokDv6QrUZWlv88FKPGU+qoOtLnnuoHSMLAELlQwhd3reqWVG726H7wE8Z9OSjQmsP9e nEBEXAFv9OFN3lNhrzH/VISgiSzXHiZEpz1l9XVXBi0wlNtqBcOTlHaihvfumLnjdyMs DD9EhStHnH2DOjAwpWckGEAi209mCqRciGAJ7eTlCqaZyxpa/tHBKeSxxyLTxqMj06SE 51BifyCZw0s3w57YRmRpSI+LlarZNbCG90D6li1km1wXvaev0UfrzkCFDjW1GTtbiQE2 dyTw== X-Gm-Message-State: ABUngvcNf5QtlVmTWD9eyg7hT22xg+BOR+6U69ZDKxnHw3lkG8r4fGOmzZ8ZbSjIh6Tx8Q== X-Received: by 10.99.56.19 with SMTP id f19mr923069pga.72.1479249728068; Tue, 15 Nov 2016 14:42:08 -0800 (PST) Received: from [10.93.138.214] (mobile-166-176-185-145.mycingular.net. [166.176.185.145]) by smtp.gmail.com with ESMTPSA id v77sm26290772pfa.85.2016.11.15.14.42.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 14:42:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (14B100) In-Reply-To: Date: Tue, 15 Nov 2016 14:42:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org> References: To: Btc Drak X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MIME_QP_LONG_LINE, 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 X-Mailman-Approved-At: Wed, 16 Nov 2016 09:08:32 +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: Tue, 15 Nov 2016 22:42:09 -0000 Actually this does nothing to provide justification for this consensus rule c= hange. It is just an attempt to deflect criticism from the fact that it is s= uch a change. e > On Nov 15, 2016, at 9:45 AM, Btc Drak wrote: >=20 > I think this is already covered in the BIP text:- >=20 > "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. >=20 > 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." >=20 >=20 > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev > wrote: >> NACK >>=20 >> 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 performanc= e >> optimization (the checks are avoidable once activated until a sufficientl= y >> deep reorg deactivates them). >>=20 >> e >>=20 >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev >> wrote: >>=20 >> Hi, >>=20 >> 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. >>=20 >> Here's the abstract: >>=20 >> 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 pas= sed >> 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. >>=20 >> The full draft can be found here: >>=20 >> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deplo= yments.mediawiki >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20 >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20