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 36C2FDAF for ; Wed, 2 Mar 2016 15:42:43 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id D83DA13B for ; Wed, 2 Mar 2016 15:42:42 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 5CC9A38A2C17 for ; Wed, 2 Mar 2016 15:42:30 +0000 (UTC) X-Hashcash: 1:25:160302:bitcoin-dev@lists.linuxfoundation.org::V68/xL6x1rgQeDzL:a87ti From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org Date: Wed, 2 Mar 2016 15:42:28 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.8; x86_64; ; ) References: <201603021456.15820.luke@dashjr.org> In-Reply-To: <201603021456.15820.luke@dashjr.org> X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201603021542.29609.luke@dashjr.org> X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_SBL, RP_MATCHES_RCVD 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: Wed, 02 Mar 2016 15:43:32 +0000 Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 15:42:43 -0000 On Wednesday, March 02, 2016 2:56:14 PM Luke Dashjr via bitcoin-dev wrote: > so it may even be possible to have such a proposal ready in time to be > deployed alongside SegWit to take effect in time for the upcoming subsidy > halving. Lapse of thinking/clarity here. This probably isn't a practical timeframe for deployment, unless/until there's an emergency situation. So if the code were bundled with SegWit, it would need some way to avoid its early activation outside of such an emergency (which could possibly be detected in code, in this case). Luke