diff options
| author | Dave Scotese <dscotese@litmocracy.com> | 2020-03-22 11:17:26 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-03-22 18:17:42 +0000 |
| commit | 977d6eb3fea9ca1b2f2974c20b860623570e81e0 (patch) | |
| tree | 10be7fcf5a1d7da47e43d66c4d1c907ed4c66f7e | |
| parent | f11f81eade3d6600a65494ac1058a797adcc7b76 (diff) | |
| download | pi-bitcoindev-977d6eb3fea9ca1b2f2974c20b860623570e81e0.tar.gz pi-bitcoindev-977d6eb3fea9ca1b2f2974c20b860623570e81e0.zip | |
Re: [bitcoin-dev] Block solving slowdown question/poll
| -rw-r--r-- | af/9d77b9c50162fd72a5cc6bc6df2bcf651d3887 | 340 |
1 files changed, 340 insertions, 0 deletions
diff --git a/af/9d77b9c50162fd72a5cc6bc6df2bcf651d3887 b/af/9d77b9c50162fd72a5cc6bc6df2bcf651d3887 new file mode 100644 index 000000000..89b6eb839 --- /dev/null +++ b/af/9d77b9c50162fd72a5cc6bc6df2bcf651d3887 @@ -0,0 +1,340 @@ +Return-Path: <dscotese@gmail.com> +Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id CBF7BC0177 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 22 Mar 2020 18:17:42 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by silver.osuosl.org (Postfix) with ESMTP id C151320385 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 22 Mar 2020 18:17:42 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from silver.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id w1kbATZE-Nz1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 22 Mar 2020 18:17:41 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com + [209.85.208.67]) + by silver.osuosl.org (Postfix) with ESMTPS id C90FD20366 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 22 Mar 2020 18:17:40 +0000 (UTC) +Received: by mail-ed1-f67.google.com with SMTP id b23so13783809edx.4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 22 Mar 2020 11:17:40 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=i/4YqXD0hna74bojg3s8G8O3BZxyQgQw5zJxp2QGO1g=; + b=F5zDmkk7N6Fcea7hpMZjasIe0+YLxn/tm9/7kqb1TSrvt1Xpk1LvQciF272ER1HCGm + 3DDOPORu5vf0FGqKvrxndREpHqWERUM34iQloeu6xhRGhfqeENK4SY/zTawIU5UDuAvE + t4n4hlQzc3k1pqXrF2D/A1ANRRBa14YqvP8rjKXGAaovNx1pilTPHK42wXAKLx4HjA2B + sncoWauSO6anQYJVqx4exP6YxiVNTQ7MQyH4RsYs9Hhn8Xa6lRrrXhF+MtKt7ljUKodR + yqfYYtv6KSatwimtqKFqDy+K3Sm5vxkeNTXeoAbu1OhIGaz4Stb6o0qvphauy5aRda9c + W9JA== +X-Gm-Message-State: ANhLgQ2j59T5OiSL4pwChdUZTvf5s3WKIsy0rRFAG8tsfQYN6qeOaVeG + Y/KMJZtf2AESy1jRQykfo6Vs8lq8CZ/EnfKtVf4= +X-Google-Smtp-Source: ADFU+vtYvo08U8ZJVRFBvr4SxV0SJi+eywxoExOq+22vDGMCITWuacSCsY50TC929O1X+FizRjJMmjNQyNRS6Xe3GBc= +X-Received: by 2002:a17:906:cd28:: with SMTP id + oz40mr16429048ejb.300.1584901059084; + Sun, 22 Mar 2020 11:17:39 -0700 (PDT) +MIME-Version: 1.0 +References: <PS2P216MB0179EC99BDE0E3388F2627F89DF30@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM> + <F713CAAC-1997-4645-A166-57358E520594@voskuil.org> +In-Reply-To: <F713CAAC-1997-4645-A166-57358E520594@voskuil.org> +From: Dave Scotese <dscotese@litmocracy.com> +Date: Sun, 22 Mar 2020 11:17:26 -0700 +Message-ID: <CAGLBAhdTMbZPwqV9YLMyHdNzLbN2DLjiOe6cBUbkwR_x4cGRmQ@mail.gmail.com> +To: Eric Voskuil <eric@voskuil.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000a18ebf05a175881b" +Subject: Re: [bitcoin-dev] Block solving slowdown question/poll +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 22 Mar 2020 18:17:42 -0000 + +--000000000000a18ebf05a175881b +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +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 =3D 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: +> +> =EF=BB=BF +> 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 th= +e +> 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 +> + + +--=20 +I like to provide some work at no charge to prove my value. Do you need a +techie? +I own Litmocracy <http://www.litmocracy.com> and Meme Racing +<http://www.memeracing.net> (in alpha). +I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which +now accepts Bitcoin. +I also code for The Dollar Vigilante <http://dollarvigilante.com/>. +"He ought to find it more profitable to play by the rules" - Satoshi +Nakamoto + +--000000000000a18ebf05a175881b +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">The software currently allows up to a two hour difference = +between the system clock and the time implied by a fresh block's timest= +amp (if I remember correctly).=C2=A0 This reliance on realtime system clock= +s can be used in a much weaker form to justify a plan for a difficulty adju= +stment 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.=C2=A0 The sooner we decide on and implement this second difficu= +lty adjustment trigger, the better.=C2=A0 It cuts off a nightmare scenario = +made possible by collusion between states through regulation and fiat, as w= +ell as any other external factors.=C2=A0 I propose that miners detecting th= +at the expected 2016 blocks have not been mined after twice the expected wa= +it time (4032 * 10 minutes =3D 28 days) ought to signal their recognition i= +n 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 ad= +justment (and also include the signal), which is then in effect for the res= +t of the 2016 blocks and the entire following difficulty period.=C2=A0 Ever= +y block from there until the modulo 2016 block should have the same signal,= + which not only indicates that a difficulty adjustment was expedited, but a= +lso that the next modulo 2016 block should not make one, but rather turn of= +f the signal.<div><br></div><div>If anyone thinks it's a good enough id= +ea for a BIP, I will consider writing one unless someone else wants to.</di= +v><div><br></div><div>Dave.</div></div></div><br><div class=3D"gmail_quote"= +><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 22, 2020 at 9:54 AM Eric= + Voskuil via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfound= +ation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><b= +lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= +ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div dir= +=3D"ltr">Mining is a lottery.</div><div dir=3D"ltr"><br></div><div dir=3D"l= +tr">e</div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Mar 22, 2020, = +at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <<a href=3D"mai= +lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li= +sts.linuxfoundation.org</a>> wrote:<br><br></blockquote></div><blockquot= +e type=3D"cite"><div dir=3D"ltr">=EF=BB=BF + + + + + +<div style=3D"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 opt= +imise mining profit by limiting the average hash rate during the retargetin= +g, saving some electricity but poorly considering the overall situation whe= +re they give opportunity to other + miners probably raising the hashrate for the next period. It is far more p= +rofitable for the ecosystem considering the whole to hold a lottery for min= +ig as has been discussed elsewhere some time ago.<br> +</div> +<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color= +:rgb(0,0,0)"> +<br> +</div> +<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color= +:rgb(0,0,0)"> +<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color= +:rgb(0,0,0)"> +Regards,</div> +<div style=3D"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=3D"gmail-m_-7843995411689266492Signature"> +<div> +<div id=3D"gmail-m_-7843995411689266492appendonsend"></div> +<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color= +:rgb(0,0,0)"> +<br> +</div> +<hr style=3D"display:inline-block;width:98%"> +<div id=3D"gmail-m_-7843995411689266492divRplyFwdMsg" dir=3D"ltr"><font sty= +le=3D"font-size:11pt" face=3D"Calibri, sans-serif" color=3D"#000000"><b>Fro= +m:</b> bitcoin-dev <<a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfou= +ndation.org" target=3D"_blank">bitcoin-dev-bounces@lists.linuxfoundation.or= +g</a>> on behalf of David A. Harding via bitcoin-dev <<a href=3D"mail= +to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis= +ts.linuxfoundation.org</a>><br> +<b>Sent:</b> Sunday, 22 March 2020 6:54 PM<br> +<b>To:</b> Dave Scotese <<a href=3D"mailto:dscotese@litmocracy.com" targ= +et=3D"_blank">dscotese@litmocracy.com</a>>; Bitcoin Protocol Discussion = +<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla= +nk">bitcoin-dev@lists.linuxfoundation.org</a>><br> +<b>Subject:</b> Re: [bitcoin-dev] Block solving slowdown question/poll</fon= +t> +<div>=C2=A0</div> +</div> +<div><font size=3D"2"><span style=3D"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<b= +r> +> then, possibly, a few months or even the unthinkable, a few eons.=C2= +=A0 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>bitco= +in-dev mailing list</span><br><span><a href=3D"mailto:bitcoin-dev@lists.lin= +uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</= +a></span><br><span><a href=3D"https://lists.linuxfoundation.org/mailman/lis= +tinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a></span><br></div></blockquote></div>___________= +____________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= + class=3D"gmail_signature"><div dir=3D"ltr">I like to provide some work at = +no charge to prove my value. Do you need a techie?=C2=A0 <br>I own <a href= +=3D"http://www.litmocracy.com" target=3D"_blank">Litmocracy</a> and <a href= +=3D"http://www.memeracing.net" target=3D"_blank">Meme Racing</a> (in alpha)= +. <br>I'm the webmaster for <a href=3D"http://www.voluntaryist.com" tar= +get=3D"_blank">The Voluntaryist</a> which now accepts Bitcoin.<br>I also co= +de for <a href=3D"http://dollarvigilante.com/" target=3D"_blank">The Dollar= + Vigilante</a>.<br>"He ought to find it more profitable to play by the= + rules" - Satoshi Nakamoto</div></div> + +--000000000000a18ebf05a175881b-- + |