path: root/af/9d77b9c50162fd72a5cc6bc6df2bcf651d3887

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&#39;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&#39;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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 &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; 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 &lt;<a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev-bounces@lists.linuxfoundation.or=
g</a>&gt; on behalf of David A. Harding via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt;<br>
<b>Sent:</b> Sunday, 22 March 2020 6:54 PM<br>
<b>To:</b> Dave Scotese &lt;<a href=3D"mailto:dscotese@litmocracy.com" targ=
et=3D"_blank">dscotese@litmocracy.com</a>&gt;; Bitcoin Protocol Discussion =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<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>
&gt; [Imagine] we also see mining power dropping off at a rate that<br>
&gt; suggests the few days [until retarget] might become a few weeks, and<b=
r>
&gt; then, possibly, a few months or even the unthinkable, a few eons.=C2=
=A0 I&#39;m<br>
&gt; curious to know if anyone has ideas on how this might be handled<br>
<br>
There are only two practical solutions I&#39;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&#39;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&#39;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>&quot;He ought to find it more profitable to play by the=
 rules&quot; - Satoshi Nakamoto</div></div>

--000000000000a18ebf05a175881b--