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 4E0D4CC8 for ; Wed, 2 Mar 2016 17:53:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D510C15A for ; Wed, 2 Mar 2016 17:53:46 +0000 (UTC) Received: by mail-io0-f174.google.com with SMTP id l127so267955283iof.3 for ; Wed, 02 Mar 2016 09:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=c3UqMusy1CpdOQvZE7yNtCJBbNFZkbxJfQ8lxiUUTQ8=; b=JYKjFXgJnurMF/JWN6PchRM73fjWZOY9z8d8HZHwtJ6XVDy5ojr+S/Plf2MrWOsLV0 CUaM1ooTQI8bp890fAe41HvXg9nOW9ezeNvwQuFRn4O+5BqLddDP3lljamJTQ88wIPGu w5TjBE9tEH06PyLDrP+ND2X7qnhiXpNXLcShZ7An4zbH22oXVOb1NhoIxgFnmgJo3nZ0 d5GG/8YWisAOEc34n7IdE4JqvX3hT7HE1jRAxZl0PmTZLNmn8/HUxqRdvDqSZo7ZDg7z 3xSjdGqsL8J+RWYf5K0uUyVgcGLziPGinX1wTvR+ZgbeAJoGBsHUUXQyUEw6pA7QQGaz rqSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=c3UqMusy1CpdOQvZE7yNtCJBbNFZkbxJfQ8lxiUUTQ8=; b=bj5cFx5Q7RrrLcKzZolnVvDmhKMvopnvzN+uo5UneDwuVXKhRa0K8AmxLATwMWlqXA 3zQ5cofT71kEX8bQz8QRi4meQWd+DSHDlwGDgdDz5HsoSgUH+IGiTDXS+eqr1gz8GHJQ rR3uEEu7pBrzzh+xyo9Zaet/5pBicOUywjI4TIasqdz7wC6BFWuVrkawoAQwe2W302sU V4ZtnjKA8gRfVz+uEq23n/g9c0XIoEIoxjrjxHvPnJ0bepi+stkyqnCSyIhyd7+uv8iA PkwVdjukXfcXrlfROT2pRjF0W13EQqtomkkscyM8rrUUF9+FAf4cnxmetKLgpxXtGtle y72w== X-Gm-Message-State: AD7BkJJXNfc+L2EpH4b2CLhNGe4TZzuqePr396guX2JYuIctU4YUexO9VyghOJNnXEqZcJEnCjhyDvgMm6vNqw== MIME-Version: 1.0 X-Received: by 10.107.14.196 with SMTP id 187mr10177951ioo.134.1456941226265; Wed, 02 Mar 2016 09:53:46 -0800 (PST) Sender: gmaxwell@gmail.com Received: by 10.107.132.75 with HTTP; Wed, 2 Mar 2016 09:53:46 -0800 (PST) In-Reply-To: <20160302171418.GA5312@localhost.localdomain> References: <201603021456.15820.luke@dashjr.org> <20160302171418.GA5312@localhost.localdomain> Date: Wed, 2 Mar 2016 17:53:46 +0000 X-Google-Sender-Auth: YWfrCQEVDW-MPghFs0Lm253byBs Message-ID: From: Gregory Maxwell To: "David A. Harding" Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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:55:38 +0000 Cc: Bitcoin Dev 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 17:53:47 -0000 On Wed, Mar 2, 2016 at 5:14 PM, David A. Harding via bitcoin-dev wrote: > On Wed, Mar 02, 2016 at 02:56:14PM +0000, Luke Dashjr via bitcoin-dev wrote: >> 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. > > Having a well-reviewed hard fork patch for rapid difficulty adjustment > would seem to be a useful reserve for all sorts of possible problems. > That said, couldn't this specific potential situation be dealt with by a > relatively simple soft fork? [...] What you are proposing makes sense only if it was believed that a very large difficulty drop would be very likely. This appears to be almost certainly untrue-- consider-- look how long ago since hashrate was 50% of what it is now, or 25% of what it is now-- this is strong evidence that supermajority of the hashrate is equipment with state of the art power efficiency. (I've also heard more directly-- but I think the this evidence is more compelling because it can't be tainted by boasting). If a pre-programmed ramp and drop is set then it has the risk of massively under-setting difficulty; which is also strongly undesirable (e.g. advanced inflation and exacerbating existing unintentional selfish mining)... and that is before suggesting that miners voluntarily take a loss of inflation now. So while I think this concern is generally implausible; I think it's prudent to have a difficulty step patch (e.g. a one time single point where a particular block is required to lower bits a set amount) ready to go in the unlikely case the network is stalled. Of course, if the alternative is "stuck" from a large hashrate drop the deployment would be both safe and relatively uncontroversial. I think the unfavorability of that approach is well matched to the implausibility of the situation, and likely the right coarse of action compared to risky interventions that would likely cause harm. The cost of developing and testing such a patch is low, and justified purely on the basis of increasing confidence that an issue would be handled (a fact _I_ am perfectly confident in; but apparently some are not). With respect what Luke was suggesting; without specifics its hard to comment, but most altcoin "tolerate difficulty drop" changes have made them much more vulnerable to partitioning attacks and other issues (e.g. strategic behavior by miners to increase inflation), and have actually been exploited in practice several times (solidcoin's being the oldest I'm aware of). Many survived a fairly long time before being shown to be pretty broken, simply because they were deployed in cases where no one cared to attack. I'm currently doubtful that particular path would be fruitful.