{"type":"rich","version":"1.0","author_name":"npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","author_url":"https://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-03-02\n📝 Original message:On Wed, Mar 02, 2016 at 05:53:46PM +0000, Gregory Maxwell wrote:\n\u003e What you are proposing makes sense only if it was believed that a very\n\u003e large difficulty drop would be very likely.\n\u003e\n\u003e This appears to be almost certainly untrue-- consider-- look how long\n\u003e ago since hashrate was 50% of what it is now, or 25% of what it is\n\u003e now-- this is strong evidence that supermajority of the hashrate is\n\u003e equipment with state of the art power efficiency.\n\nTo avoid duplication of looking up this statistic among readers, here\nare the various recent difficulties:\n\n    $ 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\n    0      blocks  ago:  163491654908.95929\n    2016   blocks  ago:  144116447847.34869\n    4032   blocks  ago:  120033340651.237\n    6048   blocks  ago:  113354299801.4711\n    8064   blocks  ago:  103880340815.4559\n    10080  blocks  ago:  93448670796.323807\n    12096  blocks  ago:  79102380900.225983\n    14112  blocks  ago:  72722780642.54718\n    16128  blocks  ago:  65848255179.702606\n    18144  blocks  ago:  62253982449.760818\n    20160  blocks  ago:  60883825480.098282\n    22176  blocks  ago:  60813224039.440353\n    24192  blocks  ago:  59335351233.86657\n    26208  blocks  ago:  56957648455.01001\n    28224  blocks  ago:  54256630327.889961\n    30240  blocks  ago:  52699842409.347008\n    32256  blocks  ago:  52278304845.591682\n    34272  blocks  ago:  51076366303.481934\n    36288  blocks  ago:  49402014931.227463\n    38304  blocks  ago:  49692386354.893837\n    40320  blocks  ago:  47589591153.625008\n    42336  blocks  ago:  48807487244.681381\n    44352  blocks  ago:  47643398017.803436\n    46368  blocks  ago:  47610564513.47126\n    48384  blocks  ago:  49446390688.24144\n    50400  blocks  ago:  46717549644.706421\n    52416  blocks  ago:  47427554950.6483\n    54432  blocks  ago:  46684376316.860291\n    56448  blocks  ago:  44455415962.343803\n    58464  blocks  ago:  41272873894.697021\n\n\u003c50% of current hash rate was last seen roughly six retarget periods (12\nweeks) ago and \u003c25% of current hash rate was last seen roughly 29 periods\n(58 weeks) ago.\n\nI think that's reasonably strong evidence for your thesis given that\nthe increases in hash rate from the introduction of new efficient\nequipment are likely partly offset by the removal from the hash rate of\nlower efficiency equipment, so the one-year tail of ~25% probably means\nthat less than 25% of operating equipment is one year old or older.\n\nHowever, it is my understanding that most mining equipment can be run at\ndifferent hash rates. Is there any evidence that high-efficiency miners\ntoday are using high clock speeds to produce more hashes per ASIC than\nthey will after halving?  Is there any way to guess at how many fewer\nhashes they might produce?\n\n\u003e If a pre-programmed ramp and drop is set then it has the risk of\n\u003e massively under-setting difficulty; which is also strongly undesirable\n\u003e (e.g. advanced inflation and exacerbating existing unintentional\n\u003e selfish mining)\n\nMaybe I'm not thinking this through thoroughly, but I don't think it's\npossible to significantly advance inflation unless the effective hash\nrate increases by more than 300% at the halving.  With the proposal\nbeing replied to, if all mining equipment operation before the\nhalving continued operating after it, the effective increase would be\n200%. That doubling in effective hash rate would've been offset in\nadvance through a reduction in the effective hash rate in the weeks\nbefore the halving.\n\nExacerbated unintentional selfish mining is a much more significant\nconcern IMO, even if it's only for a short retarget period or two. This\nis especially the case given the current high levels of centralization\nand validationless mining on the network today, which we would not want\nto reward by making those miners the only ones effectively capable of\ncreating blocks until difficulty adjusted. I had not thought of this\naspect; thank you for bringing it up.\n\n\u003e and that is before suggesting that miners voluntarily take a loss of\n\u003e inflation now.\n\nYes, I very much don't like that aspect, which is why I made sure to\nmention it.\n\n\u003e So while I think this concern is generally implausible; I think it's\n\u003e prudent to have a difficulty step patch (e.g. a one time single point\n\u003e where a particular block is required to lower bits a set amount) ready\n\u003e to go in the unlikely case the network is stalled.\n\nI think having that code ready in general is a good idea, and a one-time\nchange in nBits is sounds like a good and simple way to go about it.\n\nThank you for your insightful reply,\n\n-Dave"}