MIME-Version: 1.0
References: <CAGLBAhdtXEjhZWavgytQAOuXUaJZc=ZQyvjB2KV-YczAh-H4WQ@mail.gmail.com>
In-Reply-To: <CAGLBAhdtXEjhZWavgytQAOuXUaJZc=ZQyvjB2KV-YczAh-H4WQ@mail.gmail.com>
From: Zawy <wordsgalore@gmail.com>
Date: Wed, 5 Dec 2018 09:08:56 -0500
Message-ID: <CADtTMv=y66ERvmJzcgu0P1xt_dBkwd_qqEc=g=GfJgwhsdEPZw@mail.gmail.com>
To: Dave Scotese <dscotese@litmocracy.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] How much is too much time between difficulty
	changes?
Precedence: list

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