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 1780DA59 for ; Wed, 9 Mar 2016 20:21:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C5681A0 for ; Wed, 9 Mar 2016 20:21:49 +0000 (UTC) Received: from mcelrath.org (localhost [127.0.0.1]) by mcelrath.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id u29KLaQc016631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Mar 2016 20:21:36 GMT Received: (from mcelrath@localhost) by mcelrath.org (8.14.3/8.14.3/Submit) id u29KLaeF016630; Wed, 9 Mar 2016 20:21:36 GMT X-Authentication-Warning: mcelrath.org: mcelrath set sender to bob_bitcoin@mcelrath.org using -f Date: Wed, 9 Mar 2016 20:21:36 +0000 From: Bob McElrath To: Dave Hudson Message-ID: <20160309202135.GC4388@mcelrath.org> References: <201603021456.15820.luke@dashjr.org> <5E6E8EFD-2BC0-47F6-8005-5A63821C4276@hashingit.com> <20160308220507.GA4388@mcelrath.org> <26355E0C-1DDC-4CBD-A044-788C9C135EA6@hashingit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26355E0C-1DDC-4CBD-A044-788C9C135EA6@hashingit.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD 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 20:26:19 +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 20:21:50 -0000 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