Topic: A Decaying Block Size Limit Growth Rate (Read 588 times)
I like the idea of a blocksize that keeps increased with time since it allows planning, but then again, how can we know that Bitcoin will not suddenly become hugely mainstream and it's usage explodes in a very short period of time, requiring a bigger blocksize than what was originally planned? we can never know when something goes viral, i dont think increment in usage can be widely rendered in a nice graph. Ideally this should be dynamic. Im not sure thats possible tho.
This is just yet another in a long list of potential block size limit growth schedules. For more information, please see the original post on Reddit.
The long and short of it is, if you accept Pieter's argument that network bandwidth grows at 17.7% per year, and you accept the argument of Gavin and the majority of miners that the current technological limit to block sizes is 8 MB rather than 1 MB, then it is possible to combine the two proposals in a way that promotes growth in the short term without requiring a large initial jump in block size, yet which converges to a 17.7% growth rate in the long run.
This schedule uses a decaying growth rate for the block size limit in the same way that Satoshi chose a decaying growth rate for the block reward.
I've made a spreadsheet showing three schedules for comparison, annualized and rounded off for clarity. The first is (roughly) Pieter's proposal. The second is Gavin's proposal modified to use Pieter's 17.7% annual growth rate. And the last schedule includes an initial period of high, yet decaying growth rates, converging to a continuous 17.7% growth rate. All three schedules end once they reach approximately 128 MB, which is my proposed minimum block size (required for everyone on Earth to have the opportunity to perform two transactions per year). The ultimate maximum size is intentionally left undetermined, for simplicity of comparison.
As you can see, compared to the other two, the decaying growth rate schedule has a few advantages. First, it reaches 128 MB a full twelve years before Pieter's proposal. Secondly, there is an initial growth to 2 MB which (based on historical data) will be necessary in order to accommodate transaction growth during the next halving. Yet, there is no harsh initial jump to 8 MB as with Gavin's proposal. And, thirdly, the block size with the decaying growth schedule remains below the combined growth of an 8 MB jump with 17.7% annual increases the entire time. So it remains within the parameters of both initial conditions mentioned above.
The long and short of it is, if you accept Pieter's argument that network bandwidth grows at 17.7% per year, and you accept the argument of Gavin and the majority of miners that the current technological limit to block sizes is 8 MB rather than 1 MB, then it is possible to combine the two proposals in a way that promotes growth in the short term without requiring a large initial jump in block size, yet which converges to a 17.7% growth rate in the long run.
This schedule uses a decaying growth rate for the block size limit in the same way that Satoshi chose a decaying growth rate for the block reward.
I've made a spreadsheet showing three schedules for comparison, annualized and rounded off for clarity. The first is (roughly) Pieter's proposal. The second is Gavin's proposal modified to use Pieter's 17.7% annual growth rate. And the last schedule includes an initial period of high, yet decaying growth rates, converging to a continuous 17.7% growth rate. All three schedules end once they reach approximately 128 MB, which is my proposed minimum block size (required for everyone on Earth to have the opportunity to perform two transactions per year). The ultimate maximum size is intentionally left undetermined, for simplicity of comparison.
As you can see, compared to the other two, the decaying growth rate schedule has a few advantages. First, it reaches 128 MB a full twelve years before Pieter's proposal. Secondly, there is an initial growth to 2 MB which (based on historical data) will be necessary in order to accommodate transaction growth during the next halving. Yet, there is no harsh initial jump to 8 MB as with Gavin's proposal. And, thirdly, the block size with the decaying growth schedule remains below the combined growth of an 8 MB jump with 17.7% annual increases the entire time. So it remains within the parameters of both initial conditions mentioned above.
Jump to: