{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-03-02\n📝 Original message:On Wed, Mar 2, 2016 at 5:14 PM, David A. Harding via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On Wed, Mar 02, 2016 at 02:56:14PM +0000, Luke Dashjr via bitcoin-dev wrote:\n\u003e\u003e To alleviate this risk, it seems reasonable to propose a hardfork to the\n\u003e\u003e difficulty adjustment algorithm so it can adapt quicker to such a significant\n\u003e\u003e drop in mining rate.\n\u003e\n\u003e Having a well-reviewed hard fork patch for rapid difficulty adjustment\n\u003e would seem to be a useful reserve for all sorts of possible problems.\n\u003e That said, couldn't this specific potential situation be dealt with by a\n\u003e relatively simple soft fork?\n[...]\n\n\nWhat you are proposing makes sense only if it was believed that a very\nlarge difficulty drop would be very likely.\n\nThis appears to be almost certainly untrue-- consider-- look how long\nago since hashrate was 50% of what it is now, or 25% of what it is\nnow-- this is strong evidence that supermajority of the hashrate is\nequipment with state of the art power efficiency. (I've also heard\nmore directly-- but I think the this evidence is more compelling\nbecause it can't be tainted by boasting). If a pre-programmed ramp and\ndrop is set then it has the risk of massively under-setting\ndifficulty; which is also strongly undesirable (e.g. advanced\ninflation and exacerbating existing unintentional selfish mining)...\nand that is before suggesting that miners voluntarily take a loss of\ninflation now.\n\nSo while I think this concern is generally implausible; I think it's\nprudent to have a difficulty step patch (e.g. a one time single point\nwhere a particular block is required to lower bits a set amount) ready\nto go in the unlikely case the network is stalled. Of course, if the\nalternative is \"stuck\" from a large hashrate drop the deployment would\nbe both safe and relatively uncontroversial. I think the\nunfavorability of that approach is well matched to the implausibility\nof the situation, and likely the right coarse of action compared to\nrisky interventions that would likely cause harm. The cost of\ndeveloping and testing such a patch is low, and justified purely on\nthe basis of increasing confidence that an issue would be handled (a\nfact _I_ am perfectly confident in; but apparently some are not).\n\nWith respect what Luke was suggesting; without specifics its hard to\ncomment, but most altcoin \"tolerate difficulty drop\" changes have made\nthem much more vulnerable to partitioning attacks and other issues\n(e.g. strategic behavior by miners to increase inflation), and have\nactually been exploited in practice several times (solidcoin's being\nthe oldest I'm aware of). Many survived a fairly long time before\nbeing shown to be pretty broken, simply because they were deployed in\ncases where no one cared to attack. I'm currently doubtful that\nparticular path would be fruitful."}