On Wed, Mar 02, 2016 at 02:56:14PM +0000, Luke Dashjr via bitcoin-dev wrote: > To alleviate this risk, it seems reasonable to propose a hardfork to the > difficulty adjustment algorithm so it can adapt quicker to such a significant > drop in mining rate. BtcDrak tells me he has well-tested code for this in his > altcoin, which has seen some roller-coaster hashrates, so it may even be > possible to have such a proposal ready in time to be deployed alongside > SegWit > to take effect in time for the upcoming subsidy halving. If this slips, I > think it may be reasonable to push for at least code-readiness before July, > and possibly roll it into any other hardfork proposed before or around that > time. > > I am unaware of any reason this would be controversial, so if anyone has a > problem with such a change, please speak up sooner rather than later. Other > ideas or concerns are of course welcome as well.
Changing the difficulty adjustment algorithm significantly changes the security of the whole system, as it lets attackers create fake chains with a lot less hashing power. Given as tx fees rise this problem will hopefully be a one-time issue, a simple fixed difficulty adjustment probably makes sense. No need to bring in new algorithms here with controversial new security tradeoffs. -- https://petertodd.org 'peter'[:-1]@petertodd.org 0000000000000000045a03e0e551c4e674f301e0a8eeb217a31ad13580446626
signature.asc
Description: Digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
