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 2DEE2CCE for ; Wed, 2 Mar 2016 19:35:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.dtrt.org (mail.dtrt.org [207.192.75.234]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A76D912A for ; Wed, 2 Mar 2016 19:35:35 +0000 (UTC) Received: from harding by mail.dtrt.org with local (Exim 4.72) (envelope-from ) id 1abCYV-0000Co-Fd; Wed, 02 Mar 2016 14:35:31 -0500 Date: Wed, 2 Mar 2016 14:34:33 -0500 From: "David A. Harding" To: Gregory Maxwell Message-ID: <20160302193433.GA5990@localhost.localdomain> References: <201603021456.15820.luke@dashjr.org> <20160302171418.GA5312@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD 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 19:54:03 +0000 Cc: Bitcoin Dev 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 19:35:36 -0000 On Wed, Mar 02, 2016 at 05:53:46PM +0000, Gregory Maxwell wrote: > What you are proposing makes sense only if it was believed that a very > large difficulty drop would be very likely. > > This appears to be almost certainly untrue-- consider-- look how long > ago since hashrate was 50% of what it is now, or 25% of what it is > now-- this is strong evidence that supermajority of the hashrate is > equipment with state of the art power efficiency. To avoid duplication of looking up this statistic among readers, here are the various recent difficulties: $ for i in $( seq 0 2016 60000 ) ; do echo -n $i blocks ago:' ' ; bitcoin-cli getblock $( bitcoin-cli getblockhash $(( 400857 - i )) ) | jshon -e difficulty ; done | column -t 0 blocks ago: 163491654908.95929 2016 blocks ago: 144116447847.34869 4032 blocks ago: 120033340651.237 6048 blocks ago: 113354299801.4711 8064 blocks ago: 103880340815.4559 10080 blocks ago: 93448670796.323807 12096 blocks ago: 79102380900.225983 14112 blocks ago: 72722780642.54718 16128 blocks ago: 65848255179.702606 18144 blocks ago: 62253982449.760818 20160 blocks ago: 60883825480.098282 22176 blocks ago: 60813224039.440353 24192 blocks ago: 59335351233.86657 26208 blocks ago: 56957648455.01001 28224 blocks ago: 54256630327.889961 30240 blocks ago: 52699842409.347008 32256 blocks ago: 52278304845.591682 34272 blocks ago: 51076366303.481934 36288 blocks ago: 49402014931.227463 38304 blocks ago: 49692386354.893837 40320 blocks ago: 47589591153.625008 42336 blocks ago: 48807487244.681381 44352 blocks ago: 47643398017.803436 46368 blocks ago: 47610564513.47126 48384 blocks ago: 49446390688.24144 50400 blocks ago: 46717549644.706421 52416 blocks ago: 47427554950.6483 54432 blocks ago: 46684376316.860291 56448 blocks ago: 44455415962.343803 58464 blocks ago: 41272873894.697021 <50% of current hash rate was last seen roughly six retarget periods (12 weeks) ago and <25% of current hash rate was last seen roughly 29 periods (58 weeks) ago. I think that's reasonably strong evidence for your thesis given that the increases in hash rate from the introduction of new efficient equipment are likely partly offset by the removal from the hash rate of lower efficiency equipment, so the one-year tail of ~25% probably means that less than 25% of operating equipment is one year old or older. However, it is my understanding that most mining equipment can be run at different hash rates. Is there any evidence that high-efficiency miners today are using high clock speeds to produce more hashes per ASIC than they will after halving? Is there any way to guess at how many fewer hashes they might produce? > If a pre-programmed ramp and drop is set then it has the risk of > massively under-setting difficulty; which is also strongly undesirable > (e.g. advanced inflation and exacerbating existing unintentional > selfish mining) Maybe I'm not thinking this through thoroughly, but I don't think it's possible to significantly advance inflation unless the effective hash rate increases by more than 300% at the halving. With the proposal being replied to, if all mining equipment operation before the halving continued operating after it, the effective increase would be 200%. That doubling in effective hash rate would've been offset in advance through a reduction in the effective hash rate in the weeks before the halving. Exacerbated unintentional selfish mining is a much more significant concern IMO, even if it's only for a short retarget period or two. This is especially the case given the current high levels of centralization and validationless mining on the network today, which we would not want to reward by making those miners the only ones effectively capable of creating blocks until difficulty adjusted. I had not thought of this aspect; thank you for bringing it up. > and that is before suggesting that miners voluntarily take a loss of > inflation now. Yes, I very much don't like that aspect, which is why I made sure to mention it. > So while I think this concern is generally implausible; I think it's > prudent to have a difficulty step patch (e.g. a one time single point > where a particular block is required to lower bits a set amount) ready > to go in the unlikely case the network is stalled. I think having that code ready in general is a good idea, and a one-time change in nBits is sounds like a good and simple way to go about it. Thank you for your insightful reply, -Dave