The software currently allows up to a two hour difference between the system clock and the time implied by a fresh block's timestamp (if I remember correctly).  This reliance on realtime system clocks can be used in a much weaker form to justify a plan for a difficulty adjustment to be built into the software for when the expected block production rate is far enough behind its expected value.

We would have to agree on how far behind mining should be to justify expediting the adjustment.  The sooner we decide on and implement this second difficulty adjustment trigger, the better.  It cuts off a nightmare scenario made possible by collusion between states through regulation and fiat, as well as any other external factors.  I propose that miners detecting that the expected 2016 blocks have not been mined after twice the expected wait time (4032 * 10 minutes = 28 days) ought to signal their recognition in any block they produce, to be rejected by any miner whose clock disagrees (after taking into account the 2-hour leeway), and that any block produced on top of one with such a signal should reflect an expedited difficulty adjustment (and also include the signal), which is then in effect for the rest of the 2016 blocks and the entire following difficulty period.  Every block from there until the modulo 2016 block should have the same signal, which not only indicates that a difficulty adjustment was expedited, but also that the next modulo 2016 block should not make one, but rather turn off the signal.

If anyone thinks it's a good enough idea for a BIP, I will consider writing one unless someone else wants to.

Dave.

On Sun, Mar 22, 2020 at 9:54 AM Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Mining is a lottery.

e

On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


There seems to be the real possibility that miners are simply trying to optimise mining profit by limiting the average hash rate during the retargeting, saving some electricity but poorly considering the overall situation where they give opportunity to other miners probably raising the hashrate for the next period. It is far more profitable for the ecosystem considering the whole to hold a lottery for minig as has been discussed elsewhere some time ago.

Regards,
LORD HIS EXCELLENCY JAMES HRMH



From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of David A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Sunday, 22 March 2020 6:54 PM
To: Dave Scotese <dscotese@litmocracy.com>; Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block solving slowdown question/poll
 
On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote:
> [Imagine] we also see mining power dropping off at a rate that
> suggests the few days [until retarget] might become a few weeks, and
> then, possibly, a few months or even the unthinkable, a few eons.  I'm
> curious to know if anyone has ideas on how this might be handled

There are only two practical solutions I'm aware of:

1. Do nothing
2. Hard fork a difficulty reduction

If bitcoins retain even a small fraction of their value compared to the
previous retarget period and if most mining equipment is still available
for operation, then doing nothing is probably the best choice---as block
space becomes scarcer, transaction feerates will increase and miners
will be incentivized to increase their block production rate.

If the bitcoin price has plummeted more than, say, 99% in two weeks
with no hope of short-term recovery or if a large fraction of mining
equipment has become unusable (again, say, 99% in two weeks with no
hope of short-term recovery), then it's probably worth Bitcoin users
discussing a hard fork to reduce difficulty to a currently sustainable
level.

-Dave
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--
I like to provide some work at no charge to prove my value. Do you need a techie? 
I own Litmocracy and Meme Racing (in alpha).
I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante.
"He ought to find it more profitable to play by the rules" - Satoshi Nakamoto