{"type":"rich","version":"1.0","author_name":"npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpg","author_url":"https://nostr.ae/npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpg","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-03-02\n📝 Original message:On Wed, Mar 2, 2016 at 8:56 AM, Luke Dashjr wrote:\n\n\u003e We are coming up on the subsidy halving this July, and there have been some\n\u003e\n\nLuke,\n\nOne reason \"hard-fork to fix difficulty drop algorithm\" could be\ncontroversial is that the proposal involves a hard-fork (perhaps\nnecessarily so, at my first and second glance). There are a number of\nconcerns with hard-forks including security, deployment, participation,\nreadiness measurement, backwards incompatibility, etc. In fact, some\nBitcoin Core developers believe that hard-forks are not a good idea and\nshould not be used.\n\n# Hard-forks\n\nAn interesting (unspoken?) idea I’ve heard from a few people has been “we\nshould try to avoid all hard-forks because they are backwards\nincompatible”, another thought has been \"there should only be one more\nhard-fork if any\" and/or \"there should only be one hard-fork every 30\nyears\". I also recognize feedback from others who have mentioned \"probably\nunrealistic to expect that the consensus layer can be solidified this early\nin Bitcoin's history\". At the same time there are concerns about “slippery\nslopes”....\n\nAlso, if you are going to participate in a hard-fork then I think you\nshould make up some proposals for ensure minimal monetary loss on the old\n(non-hard-forked) chain, especially since your proposed timeline is so\nshort seems reasonable to expect even more safety-related due diligence to\nminimize money loss (such as using a new address prefix on the hard-forked\nupgrade). Anyway, it should be clear that hard-forks are an unsettled issue\nand are controversial in ways that I believe you are already aware about.\n\n# Have miners gradually reduce their hashrate instead of using a step\nfunction cliff\n\nadam3us recently proposed that miners who are thinking of turning off\nequipment should consider gradually ramping down their hashrate, as a show\nof goodwill (and substantial loss to themselves, similar to how they would\nincur losses from no longer mining after the halving). This is not\nsomething the consensus algorithm can enforce at the moment, and this\nsuggestion does not help under adversarial conditions. Since this\nsuggestion does not require a hard-fork, perhaps some effort should be made\nto query miners and figure out if they need assistance with implementing\nthis (if they happen to be interested).\n\n# Contingency planning\n\nHaving said all of the negative things above about hard-forks, I will add\nthat I do actually like the idea of having backup plans available and\ntested and gitian-built many weeks ahead of expected network event dates.\nUnfortunately this might encourage partial consensus layer hard-forks in\ntimes of extreme uncertainty such as \"emergencies\".... creating an even\nfurther emergency.\n\n# \"Indefinite backlog growth\"\n\nYou write \"the backlog would grow indefinitely until the adjustment\noccurs\". This seems to be expected behavior regardless of difficulty\nadjustment (in fact, a backlog could continue to grow even once difficulty\nadjusts downward), and the consensus protocol does not commit to\ninformation regarding that backlog anyway...\n\n# Difficulty adjustment taking time is expected\n\nThis is an expected part of the protocol, it's been mentioned since\nforever, it's well known and accounted for. Instead, we should be providing\nadvice to users about which alternative payment systems they should be\nusing if they expect instantaneous transaction confirmations. This has been\na long-standing issue, and rolling out a hard-fork is not going to fix\nmistaken assumptions from users. They will still think that confirmations\nwere meant to be instantaneous regardless of how many hard-forks you choose\nto deploy.\n\n- Bryan\nhttp://heybryan.org/\n1 512 203 0507\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160302/aefad2cc/attachment.html\u003e"}