From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 78CCCBCE for ; Wed, 2 Mar 2016 16:08:14 +0000 (UTC) X-Greylist: delayed 00:19:45 by SQLgrey-1.7.6 Received: from heron.directrouter.co.uk (heron.directrouter.co.uk [89.145.69.228]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2A878190 for ; Wed, 2 Mar 2016 16:08:12 +0000 (UTC) Received: from host86-158-172-81.range86-158.btcentralplus.com ([86.158.172.81]:58492 helo=[192.168.1.82]) by heron.directrouter.co.uk with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1ab90i-001486-CP; Wed, 02 Mar 2016 15:48:24 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Hudson 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 X-Mailer: Apple Mail (2.3112) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - heron.directrouter.co.uk X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hashingit.com X-Get-Message-Sender-Via: heron.directrouter.co.uk: authenticated_id: dave@hashingit.com X-Authenticated-Sender: heron.directrouter.co.uk: dave@hashingit.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE 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: Wed, 02 Mar 2016 16:10:01 +0000 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 16:08:14 -0000 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 = 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