📅 Original date posted:2017-11-02
📝 Original message:Is there an issue with the current difficulty adjustment algorithm? It's
worked very well as far as I can tell. Introducing a new one seems pretty
risky, what would the benefit be?
On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin cash will hard fork on Nov 13 to implement a new difficulty
> algorithm. Bitcoin itself might need to hard fork to employ a similar
> algorithm. It's about as good as they come because it followed the
> "simplest is best" route. Their averaging window is probably
> significantly too long (N=144). It's:
>
> next_D = sum (past 144 D's) * T / sum(past 144 solvetimes)
>
> They correctly did not use max(timestamp) - min(timestamp) in the
> denominator like others do.
>
> They've written the code and they're about to use it live, so Bitcoin
> will have a clear, simple, and tested path if it suddenly needs to
> hard fork due to having 20x delays for the next 2000 blocks (taking it
> a year to get unstuck).
>
> Details on it and the decision process:
> https://www.bitcoinabc.org/november
>
> It uses a nice median of 3 for the beginning and end of the window to
> help alleviate bad timestamp problems. It's nice, helps a little, but
> will also slow its response by 1 block. They also have 2x and 1/2
> limits on the adjustment per block, which is a lot more than they will
> ever need.
>
> I recommend bitcoin consider using it and making it N=50 instead of 144.
>
> I have seen that any attempts to modify the above with things like a
> low pass filter, starting the window at MTP, or preventing negative
> timestamps will only reduce its effectiveness. Bitcoin's +12 and -6
> limits on the timestamps are sufficient and well chosen, although
> something a bit smaller than the +12 might have been better.
>
> One of the contenders to the above is new and actually better, devised
> by Degnr8 and they call it D622 or wt-144.It's a little better than
> they realize. It's the only real improvement in difficulty algorithms
> since the rolling average. It gives a linearly higher weight to the
> more recent timestamps. Otherwise it is the same. Others have probably
> come across it, but there is too much noise in difficulty algorithms
> to find the good ones.
>
> # Degnr8's D622 difficulty algorithm
> # T=TargetTime, S=Solvetime
> # modified by zawy
> for i = 1 to N (from oldest to most recent block)
> t += T[i] / D[i] * i
> j += i
> next i
> next_D = j / t * T
>
> I believe any modification to the above strict mathematical weighted
> average will reduce it's effectiveness. It does not oscillate anymore
> than regular algos and rises faster and drops faster, when needed.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171102/080f5543/attachment.html>;
CryptAxe [ARCHIVE] /
npub12p…js309
2023-06-07 18:07:32
in reply to nevent1q…yma0
Author Public Key
npub12p7jzesdg8kxdg8rujr20znnd868fgugczkwh4cyxwa6gnxj5sxsnjs309Published at
2023-06-07 18:07:32Event JSON
{
"id": "5d81d7e07d4ef6a5c06ea6b04dfd59f797cb1a838bfb5e66210257b71a0df674",
"pubkey": "507d21660d41ec66a0e3e486a78a7369f474a388c0acebd70433bba44cd2a40d",
"created_at": 1686161252,
"kind": 1,
"tags": [
[
"e",
"29b18a9d3d94ae2df261451d35caed6ab5ee6f2ab3fc3f1736759599c621ef12",
"",
"root"
],
[
"e",
"fe4d23cc7fcac30ca1c98ab7779b3062e70724f6422729b7e44419b8e602cbce",
"",
"reply"
],
[
"p",
"93f19c9fec7799ea61ec4c1090ae8661c1b1c4c2bfdc1417f982e68d89dc7f0b"
]
],
"content": "📅 Original date posted:2017-11-02\n📝 Original message:Is there an issue with the current difficulty adjustment algorithm? It's\nworked very well as far as I can tell. Introducing a new one seems pretty\nrisky, what would the benefit be?\n\nOn Nov 2, 2017 4:34 PM, \"Scott Roberts via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Bitcoin cash will hard fork on Nov 13 to implement a new difficulty\n\u003e algorithm. Bitcoin itself might need to hard fork to employ a similar\n\u003e algorithm. It's about as good as they come because it followed the\n\u003e \"simplest is best\" route. Their averaging window is probably\n\u003e significantly too long (N=144). It's:\n\u003e\n\u003e next_D = sum (past 144 D's) * T / sum(past 144 solvetimes)\n\u003e\n\u003e They correctly did not use max(timestamp) - min(timestamp) in the\n\u003e denominator like others do.\n\u003e\n\u003e They've written the code and they're about to use it live, so Bitcoin\n\u003e will have a clear, simple, and tested path if it suddenly needs to\n\u003e hard fork due to having 20x delays for the next 2000 blocks (taking it\n\u003e a year to get unstuck).\n\u003e\n\u003e Details on it and the decision process:\n\u003e https://www.bitcoinabc.org/november\n\u003e\n\u003e It uses a nice median of 3 for the beginning and end of the window to\n\u003e help alleviate bad timestamp problems. It's nice, helps a little, but\n\u003e will also slow its response by 1 block. They also have 2x and 1/2\n\u003e limits on the adjustment per block, which is a lot more than they will\n\u003e ever need.\n\u003e\n\u003e I recommend bitcoin consider using it and making it N=50 instead of 144.\n\u003e\n\u003e I have seen that any attempts to modify the above with things like a\n\u003e low pass filter, starting the window at MTP, or preventing negative\n\u003e timestamps will only reduce its effectiveness. Bitcoin's +12 and -6\n\u003e limits on the timestamps are sufficient and well chosen, although\n\u003e something a bit smaller than the +12 might have been better.\n\u003e\n\u003e One of the contenders to the above is new and actually better, devised\n\u003e by Degnr8 and they call it D622 or wt-144.It's a little better than\n\u003e they realize. It's the only real improvement in difficulty algorithms\n\u003e since the rolling average. It gives a linearly higher weight to the\n\u003e more recent timestamps. Otherwise it is the same. Others have probably\n\u003e come across it, but there is too much noise in difficulty algorithms\n\u003e to find the good ones.\n\u003e\n\u003e # Degnr8's D622 difficulty algorithm\n\u003e # T=TargetTime, S=Solvetime\n\u003e # modified by zawy\n\u003e for i = 1 to N (from oldest to most recent block)\n\u003e t += T[i] / D[i] * i\n\u003e j += i\n\u003e next i\n\u003e next_D = j / t * T\n\u003e\n\u003e I believe any modification to the above strict mathematical weighted\n\u003e average will reduce it's effectiveness. It does not oscillate anymore\n\u003e than regular algos and rises faster and drops faster, when needed.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171102/080f5543/attachment.html\u003e",
"sig": "8c53c7ea9178e27b9e076a49ba9cb1633c666c099e0606e1021cdd3892aa3ccea90c602af639dc45980d3f6cddfc46a04a5ac499438b22e8302ec6f803bedaf0"
}