Bitcoin Forum
April 20, 2024, 04:15:29 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: A Decaying Block Size Limit Growth Rate  (Read 571 times)
benjamindees (OP)
Legendary
*
Offline Offline

Activity: 1330
Merit: 1000


View Profile
August 01, 2015, 10:23:48 PM
 #1

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.

Civil Liberty Through Complex Mathematics
1713629729
Hero Member
*
Offline Offline

Posts: 1713629729

View Profile Personal Message (Offline)

Ignore
1713629729
Reply with quote  #2

1713629729
Report to moderator
1713629729
Hero Member
*
Offline Offline

Posts: 1713629729

View Profile Personal Message (Offline)

Ignore
1713629729
Reply with quote  #2

1713629729
Report to moderator
1713629729
Hero Member
*
Offline Offline

Posts: 1713629729

View Profile Personal Message (Offline)

Ignore
1713629729
Reply with quote  #2

1713629729
Report to moderator
No Gods or Kings. Only Bitcoin
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1713629729
Hero Member
*
Offline Offline

Posts: 1713629729

View Profile Personal Message (Offline)

Ignore
1713629729
Reply with quote  #2

1713629729
Report to moderator
1713629729
Hero Member
*
Offline Offline

Posts: 1713629729

View Profile Personal Message (Offline)

Ignore
1713629729
Reply with quote  #2

1713629729
Report to moderator
oblivi
Hero Member
*****
Offline Offline

Activity: 700
Merit: 501


View Profile
August 01, 2015, 10:32:13 PM
 #2

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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!