[bitcoin-dev] How much is too much time between difficulty changes?

[bitcoin-dev] How much is too much time between difficulty changes?

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

The last difficulty change took about 20% longer than expected.  How large
does the time between difficulty changes have to get for us to make
changes?  In other words, if, at some point, block confirmation times are
averaging, say, hours or days, will we hardfork to speed things up?

One option is NO.  When enough economic interests align to amass the
computing power to get important bitcoin transactions into a block, then
they will work out a way to get that block confirmed.  This allows other
cryptocurrencies and technologies like LN to fill in.

There may be a group that will fork the code in order to adjust the
difficulty more rapidly, and bitcoin holders will put a value on
bitcoin-FDA ("Faster-Difficuly-Adjustment"), which is fine with me.  We can
learn how to fork peacefully from what we learned when BCH was born, and
what we learned when it split.

I think some insight into how core developers will handle increasing
demands to use faster difficulty adjustments (if they respond at all) will
be helpful, and this is why I'm asking.

Dave Scotese

[-- Attachment #2: Type: text/html, Size: 1220 bytes --]

Re: [bitcoin-dev] How much is too much time between difficulty changes?

[Zawy]

It's possible to let the difficulty linearly drop as the solvetime
goes beyond some limit (credit AS). If the limit is greater than any
delay in the past it could be backwards-compatible.

A simple daily-rolling average DA like BCH is probably the best option
if a faster DA is ever needed.

As a point of research interest (not likely to be needed by BTC), I've
taken the first above idea of "intra-block" timestamp-based difficulty
adjustment to the limit and made it symmetrical (higher D for fast
solves) and continuous. The result is a "tightening of the Poisson"
that increases "availability" (predictable solution times) at an
expense in "consistency" (orphans). It requires a very tight future
time limit to reduce timestamp manipulation. My objective was to help
small coins deal with persistent 20x hash rate changes that result in
long delays. About 3 coins have it on testnet.
https://github.com/zawy12/difficulty-algorithms/issues/36