📅 Original date posted:2016-03-09
📝 Original message:Dave Hudson [dave at 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
Bob McElrath [ARCHIVE] /
npub15n…8vrz4
2023-06-07 17:49:33
in reply to nevent1q…em6n
Author Public Key
npub15n7zls4lcps7wksmdctal39neyact74jljgsq86ylkzfn4njk95sv8vrz4Published at
2023-06-07 17:49:33Event JSON
{
"id": "48e7043bde9dbb83d70ed92b029d8bc81d7c415e14d9d5867929c8035c2b8c34",
"pubkey": "a4fc2fc2bfc061e75a1b6e17dfc4b3c93b85fab2fc91001f44fd8499d672b169",
"created_at": 1686160173,
"kind": 1,
"tags": [
[
"e",
"c19c64d0621f34bc049688bdbd88cd48f1e91c193354087b0b32d42fce855169",
"",
"root"
],
[
"e",
"5b1729c55632bfb34f789d5e4b2f99803195e83f7a485f7a1fd1e348ce7f1721",
"",
"reply"
],
[
"p",
"1e54a6de7941fa2778512f8b39026a806a830835f3e28d29701b37064e5ed5f2"
]
],
"content": "📅 Original date posted:2016-03-09\n📝 Original message:Dave Hudson [dave at hashingit.com] wrote:\n\u003e A damping-based design would seem like the obvious choice (I can think of a\n\u003e few variations on a theme here, but most are found in the realms of control\n\u003e theory somewhere). The problem, though, is working working out a timeframe\n\u003e over which to run the derivative calculations.\n\n\u003eFrom a measurement theory perspective this is straightforward. Each block is a\nmeasurement, and error propagation can be performed to derive an error on the\nderivatives.\n\nThe statistical theory of Bitcoin's block timing is known as a Poisson Point\nProcess: https://en.wikipedia.org/wiki/Poisson_point_process or temporal point\nprocess. If you google those plus \"estimation\" you'll find a metric shit-ton of\nliterature on how to handle this.\n\n\u003e The problem is the measurement of the hashrate, which is pretty inaccurate at\n\u003e best because even 2016 events isn't really enough (with a completely constant\n\u003e hash rate running indefinitely we'd see difficulty swings of up to +/- 5% even\n\u003e with the current algorithm). In order to meaningfully react to a major loss\n\u003e of hashing we'd still need to be considering a window of probably 2 weeks.\n\nYou don't want to assume it's constant in order to get a better measurement.\nThe assumption is clearly false. But, errors can be calculated, and retargeting\ncan take errors into account, because no matter what we'll always be dealing\nwith a finite sample.\n\nPersonally I don't think difficulty target variations are such a big deal, if\nthe algorithm targets that over any long time interval, the average block time\nis 10 min. Bitcoin's current algorithm fails here, with increasing hashrate (as\nwe have), it issues coins faster than its assumed schedule.\n\n--\nCheers, Bob McElrath\n\n\"For every complex problem, there is a solution that is simple, neat, and wrong.\"\n -- H. L. Mencken",
"sig": "3040b9714523f2f7377ed2f0fd14c7447748f3752e1fd6717cefebbb5ff375c953e84f2355928eb85add779200a76c185c2dcebee3fa7ef778ee07c60f9f2627"
}