Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id CBF7BC0177 for ; 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 ; 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 ; 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 ; Sun, 22 Mar 2020 18:17:40 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id b23so13783809edx.4 for ; 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: In-Reply-To: From: Dave Scotese Date: Sun, 22 Mar 2020 11:17:26 -0700 Message-ID: To: Eric Voskuil , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 ; Bitcoin Protocol Discussion > > *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 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 --000000000000a18ebf05a175881b Content-Type: text/html; 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 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.

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.

If anyone thinks it's a good enough id= ea 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@li= sts.linuxfoundation.org> wrote:

=EF=BB=BF
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.

Regards,
LORD HIS EXCELLENCY JAMES HRMH


Fro= m: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.or= g> on behalf of David A. Harding via bitcoin-dev <bitcoin-dev@lis= ts.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
=C2=A0
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.=C2= =A0 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
_______________________________________________
bitco= in-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
___________= ____________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


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