Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dave Hudson <dave@hashingit.com>
In-Reply-To: <20160308220507.GA4388@mcelrath.org>
Date: Wed, 9 Mar 2016 18:30:19 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <26355E0C-1DDC-4CBD-A044-788C9C135EA6@hashingit.com>
References: <201603021456.15820.luke@dashjr.org>
	<5E6E8EFD-2BC0-47F6-8005-5A63821C4276@hashingit.com>
	<20160308220507.GA4388@mcelrath.org>
To: Bob McElrath <bob_bitcoin@mcelrath.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Precedence: list

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:
>=20
> 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.
>=20
> 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:
>=20
>    =
http://mathworld.wolfram.com/CriticallyDampedSimpleHarmonicMotion.html
>=20
> 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. =20
>=20
> 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.
>=20
> 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.
>=20
> If solving this problem is deemed desirable, I can put some time into =
this, or
> direct others as to how to go about it.
>=20
> --
> Cheers, Bob McElrath
>=20
> "For every complex problem, there is a solution that is simple, neat, =
and wrong."
>    -- H. L. Mencken=20
>=20