diff options
| author | Gregory Maxwell <greg@xiph.org> | 2016-03-02 17:53:46 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-03-02 17:53:47 +0000 |
| commit | d3a3d048b9b68ec88142a856e1d6f67327599261 (patch) | |
| tree | bef6a552765f648096d6309d9780e6a741d5b9b0 | |
| parent | a346c9b17c5f43d0a6c956d373d851ab65773d77 (diff) | |
| download | pi-bitcoindev-d3a3d048b9b68ec88142a856e1d6f67327599261.tar.gz pi-bitcoindev-d3a3d048b9b68ec88142a856e1d6f67327599261.zip | |
Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
| -rw-r--r-- | 02/b51d7f796c2fdb74d9eebeb839ce0598f99375 | 122 |
1 files changed, 122 insertions, 0 deletions
diff --git a/02/b51d7f796c2fdb74d9eebeb839ce0598f99375 b/02/b51d7f796c2fdb74d9eebeb839ce0598f99375 new file mode 100644 index 000000000..e7499b71d --- /dev/null +++ b/02/b51d7f796c2fdb74d9eebeb839ce0598f99375 @@ -0,0 +1,122 @@ +Return-Path: <gmaxwell@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 4E0D4CC8 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 2 Mar 2016 17:53:46 +0000 (UTC) +Received: by mail-io0-f174.google.com with SMTP id l127so267955283iof.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CAAS2fgQVreFoLiHf8NhHLbT8wpSBO4WHHRU10q6Fe=3johhaoA@mail.gmail.com> +From: Gregory Maxwell <greg@xiph.org> +To: "David A. Harding" <dave@dtrt.org> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 +<bitcoin-dev@lists.linuxfoundation.org> 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. + |