From: Gregory Maxwell <greg@xiph•org>
To: "David A. Harding" <dave@dtrt•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Date: Wed, 2 Mar 2016 17:53:46 +0000 [thread overview]
Message-ID: <CAAS2fgQVreFoLiHf8NhHLbT8wpSBO4WHHRU10q6Fe=3johhaoA@mail.gmail.com> (raw)
In-Reply-To: <20160302171418.GA5312@localhost.localdomain>
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.
next prev parent reply other threads:[~2016-03-02 17:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 14:56 Luke Dashjr
2016-03-02 15:05 ` Pavel Janík
2016-03-02 15:14 ` Luke Dashjr
2016-03-02 15:24 ` Jérémie Dubois-Lacoste
[not found] ` <CAE-z3OUR8So2EM_EBeEerW-UPs0KY+whVB=jjFAHkW3xZPF2Hw@mail.gmail.com>
2016-03-02 15:54 ` Tier Nolan
2016-03-02 15:42 ` Luke Dashjr
2016-03-02 16:27 ` Paul Sztorc
2016-03-02 18:07 ` Tier Nolan
2016-03-02 19:01 ` Eric Voskuil
[not found] ` <56D74859.3090609@gmail.com>
2016-03-02 20:44 ` Eric Voskuil
2016-03-02 23:02 ` Peter Todd
2016-03-03 5:11 ` Dave Scotese
2016-03-03 10:14 ` Patrick Shirkey
2016-03-03 20:54 ` Eric Voskuil
2016-03-04 10:27 ` Tier Nolan
2016-03-02 15:48 ` Dave Hudson
2016-03-08 22:05 ` Bob McElrath
2016-03-09 18:30 ` Dave Hudson
2016-03-09 20:21 ` Bob McElrath
2016-03-09 23:24 ` Dave Hudson
2016-03-09 20:26 ` Paul Sztorc
2016-03-02 16:17 ` Bryan Bishop
2016-03-02 17:14 ` David A. Harding
2016-03-02 17:53 ` Gregory Maxwell [this message]
2016-03-02 19:34 ` David A. Harding
2016-03-03 1:06 ` Paul Sztorc
2016-03-09 17:58 ` Paul Sztorc
2016-03-02 18:20 ` Peter Todd
2016-03-03 18:27 ` Corey Haddad
2016-03-04 8:41 ` Henning Kopp
[not found] ` <CA+XQW1gfnXxxCod6cL=caGnEc66YOvaF6SJL=omUbMqwLNDP7g@mail.gmail.com>
2016-03-09 20:43 ` Paul Sztorc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgQVreFoLiHf8NhHLbT8wpSBO4WHHRU10q6Fe=3johhaoA@mail.gmail.com' \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox