From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8BAD7C2A for ; Wed, 9 Mar 2016 18:30:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from heron.directrouter.co.uk (heron.directrouter.co.uk [89.145.69.228]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA37F198 for ; Wed, 9 Mar 2016 18:30:22 +0000 (UTC) Received: from host81-151-121-25.range81-151.btcentralplus.com ([81.151.121.25]:53690 helo=[192.168.1.82]) by heron.directrouter.co.uk with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1adisG-0022HS-7u; Wed, 09 Mar 2016 18:30:20 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Hudson 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 X-Mailer: Apple Mail (2.3112) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - heron.directrouter.co.uk X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hashingit.com X-Get-Message-Sender-Via: heron.directrouter.co.uk: authenticated_id: dave@hashingit.com X-Authenticated-Sender: heron.directrouter.co.uk: dave@hashingit.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 09 Mar 2016 18:39:10 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 18:30:23 -0000 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 = 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