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 C0E46B92 for ; Wed, 2 Mar 2016 16:27:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 15C9D195 for ; Wed, 2 Mar 2016 16:27:57 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id y89so173230205qge.2 for ; Wed, 02 Mar 2016 08:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=mLiCyZNWESNFEvLRxtjZwGT0x7hkQ/sW3HYVBa6XmCs=; b=B1Sh/eeCE7pCCQJmuIv8KVeiOh6oTJkF2dOelW8KczFan7N/tkSjHk3472reUAxKCQ +KtYdfp/e3rVgH1EzC0ZUWVEr09rVKR6+Kt6HpF3OYPNk33BaGpgFuk6AIARQD66mf/r i25NcTNNitCHainuXMWOSNDvfXbsVgeGOtdme61wTGrkJw7q6GxcJrRT3oAA+CjVhDwz 4r+TXm1Q2VpAMSRAyj8bOtQDMBHReZYTGkSjrAriLe0r83hDsoI8G7Qc1OCqLgFupsdA S13VVSKK5EnQgOoZndWJ6AZSKWucs9RhI7LksNbuRlMIBxPCH0jIaSyAkVFphgVhGs1V Q0VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=mLiCyZNWESNFEvLRxtjZwGT0x7hkQ/sW3HYVBa6XmCs=; b=gxjNRI5OVpw0wbL2Lm7QPY4Lj6usjqO/ZrDgNxWWGV2Dku9ILkG/EGHN2HfSvAKE2m JivydPm5KWeMFF/oMUvc11cNQG3YuY923u4r2N3Xg+6TqnHCKltoFMry5eJa1BqumrmG cOj0hsQBYrU2KHGa4wjozeThQrupKEMgil+aGtbFV0bDQS2ogBcQDDjtMnX9gEtf1ysG pnXXFR7Z9SyHeZmUIDpFiC/JugSYvfpYChUD//d1848hswpzQlAwS4HHvEw2Rowx0CaF x/ufxqW3GVz8XN8NK+Qb2GUeYWu6EwVsK1ZBshAvf21uOmHJ+g+bE/hOBG21wL+ywN4R Q7lw== X-Gm-Message-State: AD7BkJLbU1x+2lFIJOgV2RFy+jTliKLByEPL7fXV0turY/3PAv6kqkSPrRx2F92MBZk/6w== X-Received: by 10.140.42.39 with SMTP id b36mr33651387qga.4.1456936076286; Wed, 02 Mar 2016 08:27:56 -0800 (PST) Received: from [192.168.1.101] (ool-4575fa8d.dyn.optonline.net. [69.117.250.141]) by smtp.googlemail.com with ESMTPSA id 64sm15140197qhf.40.2016.03.02.08.27.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2016 08:27:55 -0800 (PST) To: Luke Dashjr , bitcoin-dev@lists.linuxfoundation.org References: <201603021456.15820.luke@dashjr.org> <201603021542.29609.luke@dashjr.org> From: Paul Sztorc Message-ID: <56D71488.4080607@gmail.com> Date: Wed, 2 Mar 2016 11:27:52 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <201603021542.29609.luke@dashjr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW 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, 02 Mar 2016 17:57:26 +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 16:27:57 -0000 It is **essential** that emergency code be prepared. This code must be able to lower the difficulty by a large factor. --- This halving-difficulty-drop problem can, with some bad luck, get quite disastrous, very quickly. ( I did a micro-study of this problem here, for those who are unaware: http://www.truthcoin.info/blog/mining-heart-attack ) For example, it is theoretically possible that 100% of miners (not 50% or 10%) will shut off their hardware. This is because it is revenue which ~halves, not profit. If miners are all equal, difficulty causes their profit margin to narrow over time (for example, if BTC revenues are $100, and amortized fixed costs are $10, then difficulty adjustments will cause total energy costs to rise to ~ $89, such that total pre-halving profit is $1 for everyone...post-halving, profit is -$49 for everyone). So, if miners are homogenous the result is disastrous. Fortunately, miners are probably still somewhat heterogenous. However, we don't know how their power contracts (or their hardware turnover) are scheduled...many miners might (?) have already planned, in private, to close down (or substantially reduce) operations after the halving. As the coinbase rewards are currently orders of magnitude larger than tx-fees, fees are unlikely to be able to compensate for this. Users may decide to simply hold-off on transacting until fees decrease. Worse, if the price crashes (possibly as a result of uncertainty surrounding this episode), it will begin to affect miner-revenue. As a result, miners may decide to temporarily halt mining until the difficulty falls naturally. But such a temporary halt is also (potentially) disastrous. Recall the simple fact that difficulty adjustments are measured in blocks, not time (it appears that we have exactly 1015 blocks between the halving block and the next difficulty adjustment block). If excessive difficulty chokes the system, next difficulty adjustment may *never* arrive naturally. In this worst-case (but somewhat plausible) scenario, we will be *forced* to lower the difficulty via hard fork, and we will be forced to do so very very QUICKLY, as word will be spreading that the Bitcoin system has broken! If a specific hard fork is not coded and tested for this, in advance, the delay might be accompanied by endless [contentious] conversations about what else should be included in this hard fork. Worse, since all users will need to upgrade, there will be uncertainty over contentious versions, malicious agents may try to tamper with versions (to steal Bitcoins), etc. We should consider pushing a version out for users to upgrade, in advance of the halving, as soon as possible. What a disaster! I certainly hope it does not happen, but if it does we should have already agreed on what to do. One choice is "which number do we set the difficulty to?". Half may be too much, or too little. However, allow me to suggest that, if this disastrous scenario occurs, we shouldn't take any chances, and reduce difficulty by a huge proportion...80% or so. The difficulty will then quickly begin to increase again...we can warn users of the increased orphan risk, and that they should wait for many confirmations (which should be happening faster). So, "Allow the alert key to reduce the difficulty by 80%, exactly once on one of the 1015 blocks between halving and difficulty adjustment." And we should consider smoothing the rewards (as described in my post, can be done via soft fork) to prevent this from happening again. In microeconomics literature, 'kinks' in incentive-systems are almost-universally agreed to be very undesirable. Paul On 3/2/2016 10:42 AM, Luke Dashjr via bitcoin-dev wrote: > 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >