[bitcoin-dev] bitcoin-dev Digest, Vol 10, Issue 13

[Daniele Pinna via bitcoin-dev]

This seems unnecessarily complicated ("don't use cannon to kill mosquito"
kind of thing). If the community were interested in a realtime hashrate
rebalancing proposal one could simply adjust difficulty at each new block
using the current method.

If faster relaxation in case of adversity is required, it suspect that it
would suffice to perform a weighted average of the previous 2016 blocks
instead of the standard averaging that is currently done. It should be
possible to find an optimal weighting based on historical interblock timing
data. I look into it over the next couple of days.

dpinna

------------------------------
Message: 3
Date: Tue, 8 Mar 2016 22:05:07 +0000
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Content-Type: text/plain; charset=us-ascii

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

[Bob McElrath via bitcoin-dev]

This seems unnecessarily complicated ("don't use cannon to kill mosquito" kind
of thing). If the community were interested in a realtime hashrate rebalancing
proposal one could simply adjust difficulty at each new block using the current
method.

That proposal is equivalent to an under-damped oscillator, and would still see
significant oscillation between blocks if miners were switching on and off
hardware.

If faster relaxation in case of adversity is required, it suspect that it would
suffice to perform a weighted average of the previous 2016 blocks instead of
the standard averaging that is currently done. It should be possible to find an
optimal weighting based on historical interblock timing data. I look into it
over the next couple of days.

The optimal solution is the one I quote, and is well known, just not in the
bitcoin community.

"faster relaxation time" refers to the time constant of the exponential damping.
if you make it too fast, you create an over-damped oscillator. The system
cannot measure oscillation faster than the block time, so damping on shorter
timescales is useless. The optimal damping is given by the critically damped
oscillator.

Tonight at BitDevsNYC, Mike Wozniak pointed out that SPV wallets must also
calculate retargeting, but this is a terribly simple calculation, and while more
complex from a coding perspective, would not be noticeable in run-time of SPV
wallets.

--
Cheers, Bob McElrath

"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken