public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dave Hudson <dave@hashingit•com>
To: Bob McElrath <bob_bitcoin@mcelrath•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Date: Wed, 9 Mar 2016 18:30:19 +0000	[thread overview]
Message-ID: <26355E0C-1DDC-4CBD-A044-788C9C135EA6@hashingit.com> (raw)
In-Reply-To: <20160308220507.GA4388@mcelrath.org>

A damping-based design would seem like the obvious choice (I can think of a few variations on a theme here, but most are found in the realms of control theory somewhere).  The problem, though, is working working out a timeframe over which to run the derivative calculations.

The problem is the measurement of the hashrate, which is pretty inaccurate at best because even 2016 events isn't really enough (with a completely constant hash rate running indefinitely we'd see difficulty swings of up to +/- 5% even with the current algorithm).  In order to meaningfully react to a major loss of hashing we'd still need to be considering a window of probably 2 weeks.

My other concern is that if we allow quick retargets to lower difficulties then that seems likely to expose the chain to being gamed.  I'd need to think about this some more, but a few scenarios I was thinking about earlier this week appeared to risk making some types of selfish mining strategies quite a lot more profitable.

With all this said though I'll be very surprised if there's a huge drop in the hash rate come July.  The hash rate has jumped up by almost 70% in the last 6 to 7 months and that implies some pretty serious investments by miners who are quite aware of the halving.  My guess is that quite a lot of the baseline 30% has also been replaced in the same cycle.  These same miners were mining with a coin price around $250 last year so in terms of profitability I'm pretty sure that one around $400 won't be a huge concern.

I'm sure that there will be some very public "I'm done with mining" announcements from a few smaller miners come July, but I suspect the bulk of the network will have a relatively small blip and continue on its way.


Cheers,
Dave


> On 8 Mar 2016, at 22:05, Bob McElrath <bob_bitcoin@mcelrath•org> wrote:
> 
> Dave Hudson via bitcoin-dev [bitcoin-dev@lists•linuxfoundation.org] wrote:
>> I think the biggest question here would be how would the difficulty
>> retargeting be changed?  Without seeing the algorithm proposal it's difficult
>> to assess the impact that it would have, but my intuition is that this is
>> likely to be problematic.
> 
> I have no comment on whether this will be *needed* but there's a simple
> algorithm that I haven't seen any coin adopt, that I think needs to be: the
> critically damped harmonic oscillator:
> 
>    http://mathworld.wolfram.com/CriticallyDampedSimpleHarmonicMotion.html
> 
> In dynamical systems one does a derivative expansion.  Here we want to find the
> first and second derivatives (in time) of the hashrate.  These can be determined
> by a method of finite differences, or fancier algorithms which use a quadratic
> or quartic polynomial approximation.  Two derivatives are generally all that is
> needed, and the resulting dynamical system is a damped harmonic oscillator.  
> 
> A damped harmonic oscillator is basically how your car's shock absorbers work.
> The relevant differential equation has two parameters: the oscillation frequency
> and damping factor.  The maximum oscillation frequency is the block rate.  Any
> oscillation faster than the block rate cannot be measured by block times.  The
> damping rate is an exponential decay and for critical damping is twice the
> oscillation frequency.
> 
> So, this is a zero parameter, optimal damping solution for a varying hashrate.
> This is inherently a numeric approximation solution to a differential equation,
> so questions of approximations for the hashrate enter, but that's all.  Weak
> block proposals will be able to get better approximations to the hashrate.
> 
> If solving this problem is deemed desirable, I can put some time into this, or
> direct others as to how to go about it.
> 
> --
> Cheers, Bob McElrath
> 
> "For every complex problem, there is a solution that is simple, neat, and wrong."
>    -- H. L. Mencken 
> 



  reply	other threads:[~2016-03-09 18:30 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 [this message]
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
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=26355E0C-1DDC-4CBD-A044-788C9C135EA6@hashingit.com \
    --to=dave@hashingit$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=bob_bitcoin@mcelrath$(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