path: root/e0/00aba9cb4824b86fbfa2415083c419b15c87a9

Return-Path: <corey3@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 74782CC0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Mar 2016 18:27:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com
	[209.85.213.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C64D915E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Mar 2016 18:27:35 +0000 (UTC)
Received: by mail-ig0-f175.google.com with SMTP id z8so1163025ige.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 03 Mar 2016 10:27:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc; bh=90YtnWB3Sj6+rME1cDx2Saca+zJl/xp9aw7OuK/sWCo=;
	b=WYWyOHPu+QoLa5aArcQ7CYehCo+WWz8+9vCIq7hhJqHwzB1PhwyKxG35BRZAeCmMGe
	ccoRt2SunAMBRh+vt2mJ9eZjn4udE23eLa5vMtGyliU/Rh8x+aLkdLKVzBFLRdyxyi0x
	gEDpXJQXX/I6BI6t3wrAE51TAvy9H0MzII8oZX1oK6B+8FDUak0ghbe9S9AAA/FzNkEt
	e4AYB/malNiSOYhlK9NEK4ut+KYfi3bEh18d2k/lD+Ewc0doEXPgCXBusxhh2hYOOesE
	P9t0qPdee5V8ED9Y8kXZYCKyTZ0zRDNz9pAtUc8+jAphvy3ij5Bk9jJ+e/4N+7fibcJe
	OvPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc;
	bh=90YtnWB3Sj6+rME1cDx2Saca+zJl/xp9aw7OuK/sWCo=;
	b=YdB4s4ZHuSM8Irr7EUpifg4n6uxZlw/343h+XRk5aWt2ce3sk9e8l9Z9DZqVjeo9n9
	dAwz1EL7NeZxQVIElrL1VRa7S+YCoMZEF3eadmA06qTjB5J0NjEvoY8+ywTDP5QF2+41
	s8FgTa44IQIP+/pGBqnfBvS64wS4xXlzRw88+TZNjYixhGQjZz/K/l30VQzLsqyAaEnn
	MZEyQsIdH7I6oLScd7dD3NrcjU+4AfjrrVViJpVjuUBD/IP2A4tRcMEScm3PrRIFp6s5
	7s982EfELkarQj2X/osQHczwEZy88oRlvE6/wYJKVH5ZJRW8IAdfZLz/Zgp/FrGi8Vst
	adfw==
X-Gm-Message-State: AD7BkJKBw/GGykn7IOZUsk5MzwW0kQ32RD9S3eGag37nshDYrx0cu22zsL+4QW+iXRHRb7aSmUwV3z3052UuiA==
MIME-Version: 1.0
X-Received: by 10.50.83.73 with SMTP id o9mr528210igy.90.1457029655180; Thu,
	03 Mar 2016 10:27:35 -0800 (PST)
Received: by 10.64.71.73 with HTTP; Thu, 3 Mar 2016 10:27:35 -0800 (PST)
In-Reply-To: <201603021456.15820.luke@dashjr.org>
References: <201603021456.15820.luke@dashjr.org>
Date: Thu, 3 Mar 2016 10:27:35 -0800
Message-ID: <CAK_HAC9v8ZuOKBQQZ4TJa2vdmEuOM-ykqEAMvaLgUn-Cr13Yww@mail.gmail.com>
From: Corey Haddad <corey3@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=089e0116076c06418c052d292736
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 03 Mar 2016 21:00:21 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Thu, 03 Mar 2016 18:27:36 -0000

--089e0116076c06418c052d292736
Content-Type: text/plain; charset=UTF-8

Since the root cause of what you are trying to address is the reward
having, I'd suggest considering an adjustment to the having schedule.
Instead of their being a large supply shock every four years, perhaps the
reward could drop every 52,500 blocks (yearly), or even at each difficulty
adjustment, in such a way that the inflation curve is smoothed out.  The
exponential decay rate would be preserved, so overall economic philosophy
would be preserved.

I'm guessing hesitance to this approach would lie in a reluctance to tinker
with Bitcoin's 'economic contract', and slippery slope concerns about might
be the next change (21M?).  However, I think it could actually increase
confidence in the system if the community is able to demonstrate a good
process for making such decisions, and show that we can separate the
meaningful underlying principles, such as the coin limit and overall
inflation rate, from what is more akin to an implementation detail, as I
consider the large-step reward reduction to be.

I'm not too worried about the impact of the having as is, but adjusting the
economic parameter would be a safer and simpler way to address the concerns
than to tinker with the difficulty targeting mechanism, which is at the
heart of Bitcoin's security

On Wed, Mar 2, 2016 at 6:56 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We are coming up on the subsidy halving this July, and there have been some
> concerns raised that a non-trivial number of miners could potentially drop
> off
> the network. This would result in a significantly longer block interval,
> which
> also means a higher per-block transaction volume, which could cause the
> block
> size limit to legitimately be hit much sooner than expected. Furthermore,
> due
> to difficulty adjustment being measured exclusively in blocks, the time
> until
> it adjusts to compensate would be prolonged.
>
> For example, if 50% of miners dropped off the network, blocks would be
> every
> 20 minutes on average and contain double the transactions they presently
> do.
> Even double would be approximately 850-900k, which potentially bumps up
> against the hard limit when empty blocks are taken into consideration. This
> situation would continue for a full month if no changes are made. If more
> miners drop off the network, most of this becomes linearly worse, but due
> to
> hitting the block size limit, the backlog would grow indefinitely until the
> adjustment occurs.
>
> To alleviate this risk, it seems reasonable to propose a hardfork to the
> difficulty adjustment algorithm so it can adapt quicker to such a
> significant
> drop in mining rate. BtcDrak tells me he has well-tested code for this in
> his
> altcoin, which has seen some roller-coaster hashrates, so it may even be
> possible to have such a proposal ready in time to be deployed alongside
> SegWit
> to take effect in time for the upcoming subsidy halving. If this slips, I
> think it may be reasonable to push for at least code-readiness before July,
> and possibly roll it into any other hardfork proposed before or around that
> time.
>
> I am unaware of any reason this would be controversial, so if anyone has a
> problem with such a change, please speak up sooner rather than later. Other
> ideas or concerns are of course welcome as well.
>
> Thanks,
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--089e0116076c06418c052d292736
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Since the root cause of what you are trying to a=
ddress is the reward having, I&#39;d suggest considering an adjustment to t=
he having schedule.=C2=A0 Instead of their being a large supply shock every=
 four years, perhaps the reward could drop every 52,500 blocks (yearly), or=
 even at each difficulty adjustment, in such a way that the inflation curve=
 is smoothed out.=C2=A0 The exponential decay rate would be preserved, so o=
verall economic philosophy would be preserved.<br><br></div>I&#39;m guessin=
g hesitance to this approach would lie in a reluctance to tinker with Bitco=
in&#39;s &#39;economic contract&#39;, and slippery slope concerns about mig=
ht be the next change (21M?).=C2=A0 However, I think it could actually incr=
ease confidence in the system if the community is able to demonstrate a goo=
d process for making such decisions, and show that we can separate the mean=
ingful underlying principles, such as the coin limit and overall inflation =
rate, from what is more akin to an implementation detail, as I consider the=
 large-step reward reduction to be.<br><br></div><div>I&#39;m not too worri=
ed about the impact of the having as is, but adjusting the economic paramet=
er would be a safer and simpler way to address the concerns than to tinker =
with the difficulty targeting mechanism, which is at the heart of Bitcoin&#=
39;s security<br></div></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Wed, Mar 2, 2016 at 6:56 AM, Luke Dashjr via bitcoin-dev <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">We are coming up on the subsidy halvi=
ng this July, and there have been some<br>
concerns raised that a non-trivial number of miners could potentially drop =
off<br>
the network. This would result in a significantly longer block interval, wh=
ich<br>
also means a higher per-block transaction volume, which could cause the blo=
ck<br>
size limit to legitimately be hit much sooner than expected. Furthermore, d=
ue<br>
to difficulty adjustment being measured exclusively in blocks, the time unt=
il<br>
it adjusts to compensate would be prolonged.<br>
<br>
For example, if 50% of miners dropped off the network, blocks would be ever=
y<br>
20 minutes on average and contain double the transactions they presently do=
.<br>
Even double would be approximately 850-900k, which potentially bumps up<br>
against the hard limit when empty blocks are taken into consideration. This=
<br>
situation would continue for a full month if no changes are made. If more<b=
r>
miners drop off the network, most of this becomes linearly worse, but due t=
o<br>
hitting the block size limit, the backlog would grow indefinitely until the=
<br>
adjustment occurs.<br>
<br>
To alleviate this risk, it seems reasonable to propose a hardfork to the<br=
>
difficulty adjustment algorithm so it can adapt quicker to such a significa=
nt<br>
drop in mining rate. BtcDrak tells me he has well-tested code for this in h=
is<br>
altcoin, which has seen some roller-coaster hashrates, so it may even be<br=
>
possible to have such a proposal ready in time to be deployed alongside Seg=
Wit<br>
to take effect in time for the upcoming subsidy halving. If this slips, I<b=
r>
think it may be reasonable to push for at least code-readiness before July,=
<br>
and possibly roll it into any other hardfork proposed before or around that=
<br>
time.<br>
<br>
I am unaware of any reason this would be controversial, so if anyone has a<=
br>
problem with such a change, please speak up sooner rather than later. Other=
<br>
ideas or concerns are of course welcome as well.<br>
<br>
Thanks,<br>
<br>
Luke<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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></div>

--089e0116076c06418c052d292736--