public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Hardfork to fix difficulty drop algorithm
@ 2016-03-02 14:56 Luke Dashjr
  2016-03-02 15:05 ` Pavel Janík
                   ` (6 more replies)
  0 siblings, 7 replies; 31+ messages in thread
From: Luke Dashjr @ 2016-03-02 14:56 UTC (permalink / raw)
  To: bitcoin-dev

We are coming up on the subsidy halving this July, and there have been some 
concerns raised that a non-trivial number of miners could potentially drop off 
the network. This would result in a significantly longer block interval, which 
also means a higher per-block transaction volume, which could cause the block 
size limit to legitimately be hit much sooner than expected. Furthermore, due 
to difficulty adjustment being measured exclusively in blocks, the time until 
it adjusts to compensate would be prolonged.

For example, if 50% of miners dropped off the network, blocks would be every 
20 minutes on average and contain double the transactions they presently do. 
Even double would be approximately 850-900k, which potentially bumps up 
against the hard limit when empty blocks are taken into consideration. This 
situation would continue for a full month if no changes are made. If more 
miners drop off the network, most of this becomes linearly worse, but due to 
hitting the block size limit, the backlog would grow indefinitely until the 
adjustment occurs.

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.

Thanks,

Luke


^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2016-03-09 23:24 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-02 14:56 [bitcoin-dev] Hardfork to fix difficulty drop algorithm Luke Dashjr
2016-03-02 15:05 ` Pavel Janík
2016-03-02 15:14   ` Luke Dashjr
2016-03-02 15:24     ` Jérémie Dubois-Lacoste
     [not found]     ` <CAE-z3OUR8So2EM_EBeEerW-UPs0KY+whVB=jjFAHkW3xZPF2Hw@mail.gmail.com>
2016-03-02 15:54       ` Tier Nolan
2016-03-02 15:42 ` Luke Dashjr
2016-03-02 16:27   ` Paul Sztorc
2016-03-02 18:07     ` Tier Nolan
2016-03-02 19:01       ` Eric Voskuil
     [not found]         ` <56D74859.3090609@gmail.com>
2016-03-02 20:44           ` Eric Voskuil
2016-03-02 23:02         ` Peter Todd
2016-03-03  5:11           ` Dave Scotese
2016-03-03 10:14           ` Patrick Shirkey
2016-03-03 20:54           ` Eric Voskuil
2016-03-04 10:27             ` Tier Nolan
2016-03-02 15:48 ` Dave Hudson
2016-03-08 22:05   ` Bob McElrath
2016-03-09 18:30     ` Dave Hudson
2016-03-09 20:21       ` Bob McElrath
2016-03-09 23:24         ` Dave Hudson
2016-03-09 20:26       ` Paul Sztorc
2016-03-02 16:17 ` Bryan Bishop
2016-03-02 17:14 ` David A. Harding
2016-03-02 17:53   ` Gregory Maxwell
2016-03-02 19:34     ` David A. Harding
2016-03-03  1:06     ` Paul Sztorc
2016-03-09 17:58       ` Paul Sztorc
2016-03-02 18:20 ` Peter Todd
2016-03-03 18:27 ` Corey Haddad
2016-03-04  8:41   ` Henning Kopp
     [not found]     ` <CA+XQW1gfnXxxCod6cL=caGnEc66YOvaF6SJL=omUbMqwLNDP7g@mail.gmail.com>
2016-03-09 20:43       ` Paul Sztorc

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox