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

Dave Hudson [dave@hashingit.com] wrote:
> 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.

From a measurement theory perspective this is straightforward.  Each block is a
measurement, and error propagation can be performed to derive an error on the
derivatives.

The statistical theory of Bitcoin's block timing is known as a Poisson Point
Process: https://en.wikipedia.org/wiki/Poisson_point_process or temporal point
process.  If you google those plus "estimation" you'll find a metric shit-ton of
literature on how to handle this.

> 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.

You don't want to assume it's constant in order to get a better measurement.
The assumption is clearly false.  But, errors can be calculated, and retargeting
can take errors into account, because no matter what we'll always be dealing
with a finite sample.

Personally I don't think difficulty target variations are such a big deal, if
the algorithm targets that over any long time interval, the average block time
is 10 min.  Bitcoin's current algorithm fails here, with increasing hashrate (as
we have), it issues coins faster than its assumed schedule.

--
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 20:21 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-02 14:56 [bitcoin-dev] Hardfork to fix difficulty drop algorithm 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 [this message]
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=20160309202135.GC4388@mcelrath.org \
    --to=bob_bitcoin@mcelrath.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dave@hashingit.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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