{"type":"rich","version":"1.0","author_name":"npub1re22dhneg8azw7z3979njqn2sp4gxzp4703g62tsrvmsvnj76heqj679nu","author_url":"https://nostr.ae/npub1re22dhneg8azw7z3979njqn2sp4gxzp4703g62tsrvmsvnj76heqj679nu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-03-09\n📝 Original message:\u003e On 9 Mar 2016, at 20:21, Bob McElrath \u003cbob_bitcoin at mcelrath.org\u003e wrote:\n\u003e \n\u003e Dave Hudson [dave at hashingit.com] wrote:\n\u003e\u003e A damping-based design would seem like the obvious choice (I can think of a\n\u003e\u003e few variations on a theme here, but most are found in the realms of control\n\u003e\u003e theory somewhere).  The problem, though, is working working out a timeframe\n\u003e\u003e over which to run the derivative calculations.\n\u003e \n\u003e From a measurement theory perspective this is straightforward.  Each block is a\n\u003e measurement, and error propagation can be performed to derive an error on the\n\u003e derivatives.\n\nSure, but I think there are 2 problems:\n\n1) My guess is that errors over anything but a long period are probably too large to be very useful.\n\n2) We don't have a strong notion of time that is part of the consensus.  Sure, blocks have timestamps but they're very loosely controlled (can't be more than 2 hours ahead of what any validating node thinks the time might be).  Difficulty can't be calculated based on anything that's not part of the consensus data.\n\n\u003e The statistical theory of Bitcoin's block timing is known as a Poisson Point\n\u003e Process: https://en.wikipedia.org/wiki/Poisson_point_process or temporal point\n\u003e process.  If you google those plus \"estimation\" you'll find a metric shit-ton of\n\u003e literature on how to handle this.\n\nStrictly it's a non-homogeneous Poisson Process, but I'm pretty familiar with the concept (Google threw one of my own blog posts back at me: http://hashingit.com/analysis/27-hash-rate-headaches, but I actually prefer this one: http://hashingit.com/analysis/30-finding-2016-blocks because most people seem to find it easier to visualize).\n\n\u003e\u003e The problem is the measurement of the hashrate, which is pretty inaccurate at\n\u003e\u003e best because even 2016 events isn't really enough (with a completely constant\n\u003e\u003e hash rate running indefinitely we'd see difficulty swings of up to +/- 5% even\n\u003e\u003e with the current algorithm).  In order to meaningfully react to a major loss\n\u003e\u003e of hashing we'd still need to be considering a window of probably 2 weeks.\n\u003e \n\u003e You don't want to assume it's constant in order to get a better measurement.\n\u003e The assumption is clearly false.  But, errors can be calculated, and retargeting\n\u003e can take errors into account, because no matter what we'll always be dealing\n\u003e with a finite sample.\n\nAgreed, it's a thought experiment I ran in May 2014 (http://hashingit.com/analysis/28-reach-for-the-ear-defenders).  I found that many people's intuition is that there would be little or no difficulty changes in such a scenario, but the intuition isn't reliable.  Given a static hash rate the NHPP behaviour introduces a surprisingly large amount of noise (often much larger than any signal over a period of even weeks).  Any measurements in the order of even a few days has so much noise that it's practically unusable.  I just realized that unlike some of my other sims this one didn't make it to github; I'll fix that later this week.\n\n\nCheers,\nDave"}