<div dir="ltr">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.<div><br></div><div>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.<div><br></div><div>If anyone thinks it's a good enough idea for a BIP, I will consider writing one unless someone else wants to.</div><div><br></div><div>Dave.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 22, 2020 at 9:54 AM Eric Voskuil via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr">Mining is a lottery.</div><div dir="ltr"><br></div><div dir="ltr">e</div><div dir="ltr"><br><blockquote type="cite">On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
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.<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Regards,</div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
LORD HIS EXCELLENCY JAMES HRMH </div>
</div>
<div><br>
</div>
<div>
<div id="gmail-m_-7843995411689266492Signature">
<div>
<div id="gmail-m_-7843995411689266492appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-7843995411689266492divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> bitcoin-dev <<a href="mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target="_blank">bitcoin-dev-bounces@lists.linuxfoundation.org</a>> on behalf of David A. Harding via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>><br>
<b>Sent:</b> Sunday, 22 March 2020 6:54 PM<br>
<b>To:</b> Dave Scotese <<a href="mailto:dscotese@litmocracy.com" target="_blank">dscotese@litmocracy.com</a>>; Bitcoin Protocol Discussion <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>><br>
<b>Subject:</b> Re: [bitcoin-dev] Block solving slowdown question/poll</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote:<br>
> [Imagine] we also see mining power dropping off at a rate that<br>
> suggests the few days [until retarget] might become a few weeks, and<br>
> then, possibly, a few months or even the unthinkable, a few eons. I'm<br>
> curious to know if anyone has ideas on how this might be handled<br>
<br>
There are only two practical solutions I'm aware of:<br>
<br>
1. Do nothing<br>
2. Hard fork a difficulty reduction<br>
<br>
If bitcoins retain even a small fraction of their value compared to the<br>
previous retarget period and if most mining equipment is still available<br>
for operation, then doing nothing is probably the best choice---as block<br>
space becomes scarcer, transaction feerates will increase and miners<br>
will be incentivized to increase their block production rate.<br>
<br>
If the bitcoin price has plummeted more than, say, 99% in two weeks<br>
with no hope of short-term recovery or if a large fraction of mining<br>
equipment has become unusable (again, say, 99% in two weeks with no<br>
hope of short-term recovery), then it's probably worth Bitcoin users<br>
discussing a hard fork to reduce difficulty to a currently sustainable<br>
level.<br>
<br>
-Dave<br>
</div>
</span></font></div>
</div>
</div>
</div>
<span>_______________________________________________</span><br><span>bitcoin-dev mailing list</span><br><span><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">I like to provide some work at no charge to prove my value. Do you need a techie? <br>I own <a href="http://www.litmocracy.com" target="_blank">Litmocracy</a> and <a href="http://www.memeracing.net" target="_blank">Meme Racing</a> (in alpha). <br>I'm the webmaster for <a href="http://www.voluntaryist.com" target="_blank">The Voluntaryist</a> which now accepts Bitcoin.<br>I also code for <a href="http://dollarvigilante.com/" target="_blank">The Dollar Vigilante</a>.<br>"He ought to find it more profitable to play by the rules" - Satoshi Nakamoto</div></div>