rich1.0npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpghttps://nostr.ae/npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpgnjumphttps://nostr.ae📅 Original date posted:2016-03-02 📝 Original message:On Wed, Mar 2, 2016 at 8:56 AM, Luke Dashjr wrote: > We are coming up on the subsidy halving this July, and there have been some > Luke, One reason "hard-fork to fix difficulty drop algorithm" could be controversial is that the proposal involves a hard-fork (perhaps necessarily so, at my first and second glance). There are a number of concerns with hard-forks including security, deployment, participation, readiness measurement, backwards incompatibility, etc. In fact, some Bitcoin Core developers believe that hard-forks are not a good idea and should not be used. # Hard-forks An interesting (unspoken?) idea I’ve heard from a few people has been “we should try to avoid all hard-forks because they are backwards incompatible”, another thought has been "there should only be one more hard-fork if any" and/or "there should only be one hard-fork every 30 years". I also recognize feedback from others who have mentioned "probably unrealistic to expect that the consensus layer can be solidified this early in Bitcoin's history". At the same time there are concerns about “slippery slopes”.... Also, if you are going to participate in a hard-fork then I think you should make up some proposals for ensure minimal monetary loss on the old (non-hard-forked) chain, especially since your proposed timeline is so short seems reasonable to expect even more safety-related due diligence to minimize money loss (such as using a new address prefix on the hard-forked upgrade). Anyway, it should be clear that hard-forks are an unsettled issue and are controversial in ways that I believe you are already aware about. # Have miners gradually reduce their hashrate instead of using a step function cliff adam3us recently proposed that miners who are thinking of turning off equipment should consider gradually ramping down their hashrate, as a show of goodwill (and substantial loss to themselves, similar to how they would incur losses from no longer mining after the halving). This is not something the consensus algorithm can enforce at the moment, and this suggestion does not help under adversarial conditions. Since this suggestion does not require a hard-fork, perhaps some effort should be made to query miners and figure out if they need assistance with implementing this (if they happen to be interested). # Contingency planning Having said all of the negative things above about hard-forks, I will add that I do actually like the idea of having backup plans available and tested and gitian-built many weeks ahead of expected network event dates. Unfortunately this might encourage partial consensus layer hard-forks in times of extreme uncertainty such as "emergencies".... creating an even further emergency. # "Indefinite backlog growth" You write "the backlog would grow indefinitely until the adjustment occurs". This seems to be expected behavior regardless of difficulty adjustment (in fact, a backlog could continue to grow even once difficulty adjusts downward), and the consensus protocol does not commit to information regarding that backlog anyway... # Difficulty adjustment taking time is expected This is an expected part of the protocol, it's been mentioned since forever, it's well known and accounted for. Instead, we should be providing advice to users about which alternative payment systems they should be using if they expect instantaneous transaction confirmations. This has been a long-standing issue, and rolling out a hard-fork is not going to fix mistaken assumptions from users. They will still think that confirmations were meant to be instantaneous regardless of how many hard-forks you choose to deploy. - Bryan http://heybryan.org/ 1 512 203 0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160302/aefad2cc/attachment.html>