Date: Wed, 2 Mar 2016 14:34:33 -0500
From: "David A. Harding" <dave@dtrt.org>
To: Gregory Maxwell <greg@xiph.org>
Message-ID: <20160302193433.GA5990@localhost.localdomain>
References: <201603021456.15820.luke@dashjr.org>
	<20160302171418.GA5312@localhost.localdomain>
	<CAAS2fgQVreFoLiHf8NhHLbT8wpSBO4WHHRU10q6Fe=3johhaoA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAS2fgQVreFoLiHf8NhHLbT8wpSBO4WHHRU10q6Fe=3johhaoA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Precedence: list

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