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_bitc...@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 > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
