Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dave Hudson <dave@hashingit.com>
In-Reply-To: <201603021456.15820.luke@dashjr.org>
Date: Wed, 2 Mar 2016 15:48:21 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E6E8EFD-2BC0-47F6-8005-5A63821C4276@hashingit.com>
References: <201603021456.15820.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Precedence: list

I think the biggest question here would be how would the difficulty =
retargeting be changed?  Without seeing the algorithm proposal it's =
difficult to assess the impact that it would have, but my intuition is =
that this is likely to be problematic.

Probabilistically the network sees surprisingly frequent swings of =
+/-20% in terms of the block finding rate on any given day, while the =
statistical noise over a 2016 block period can be more than +/-5%.  Any =
change would still have to require a fairly significant period of time =
before there would be a reasonable level of confidence that the hash =
rate really had fallen as opposed to just seeing statistical noise =
(http://hashingit.com/analysis/29-lies-damned-lies-and-bitcoin-difficultie=
s and http://hashingit.com/analysis/28-reach-for-the-ear-defenders).

How long would be required to deem that the hash rate had dramatically =
fallen?  Would such a change be a one-time event or would it be =
ever-present?

If we were to say that if the hash rate dropped 50% in one day (which =
could, of course be a 30% real drop and 20% variance) and the difficulty =
was retargeted to 50% lower then that would have to be matched with a =
similar rapid retarget if it were to increase by a similar amount.  =
Failing to do this both ways this would introduce an economic incentive =
for large miners to suppress the difficulty and gain dramatically larger =
numbers of block rewards.  The current fixed block count per difficulty =
change prevents this because the daily losses while suppressing hashing =
outweigh the potential gains when it's re-added.


Cheers,
Dave


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