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 DCCCAD7A for ; Wed, 2 Mar 2016 14:56:29 +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 8E3A01A2 for ; Wed, 2 Mar 2016 14:56:29 +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 94DD938A2C8E for ; Wed, 2 Mar 2016 14:56:16 +0000 (UTC) X-Hashcash: 1:25:160302:bitcoin-dev@lists.linuxfoundation.org::Hta0ZKVmglMdgNSl:a9eky From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org Date: Wed, 2 Mar 2016 14:56:14 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.8; x86_64; ; ) 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="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201603021456.15820.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 Subject: [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 14:56:30 -0000 We are coming up on the subsidy halving this July, and there have been some concerns raised that a non-trivial number of miners could potentially drop off the network. This would result in a significantly longer block interval, which also means a higher per-block transaction volume, which could cause the block size limit to legitimately be hit much sooner than expected. Furthermore, due to difficulty adjustment being measured exclusively in blocks, the time until it adjusts to compensate would be prolonged. For example, if 50% of miners dropped off the network, blocks would be every 20 minutes on average and contain double the transactions they presently do. Even double would be approximately 850-900k, which potentially bumps up against the hard limit when empty blocks are taken into consideration. This situation would continue for a full month if no changes are made. If more miners drop off the network, most of this becomes linearly worse, but due to hitting the block size limit, the backlog would grow indefinitely until the adjustment occurs. To alleviate this risk, it seems reasonable to propose a hardfork to the difficulty adjustment algorithm so it can adapt quicker to such a significant drop in mining rate. BtcDrak tells me he has well-tested code for this in his altcoin, which has seen some roller-coaster hashrates, 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. If this slips, I think it may be reasonable to push for at least code-readiness before July, and possibly roll it into any other hardfork proposed before or around that time. I am unaware of any reason this would be controversial, so if anyone has a problem with such a change, please speak up sooner rather than later. Other ideas or concerns are of course welcome as well. Thanks, Luke