Difference between revisions of "Dynamic max block size"

Latest revision as of 06:36, 16 July 2014

There's a lot of heated debate concerning the maximum block size within the Bitcoin community, and one new network protocol worth discussing is the idea of a dynamic max block size. The idea is to make the max block size a free floating value determined perhaps by several factors. Two methods which immediately come to my mind are 1) a mining-based voting system and 2) a system which analyzes some number of previous blocks and calculates the average block size to derive a new block size limit (eg 2*average).

A voting system sounds feasible and it could allow us to manage the max block size through group consensus, but it gives groups such as mining pools a lot of power over what the max block size will be. A better solution is to simply calculate the average size of some number of recent blocks and then multiply that by some value to derive the new maximum block size, with some arbitrary lower limit. That way we don't need to store all the voting data in the blocks. This is the approach we decided to take with Cryptonite.

Even with our light weight scheme there does need to be a max block size because our network can only handle so much traffic before it virtually stops working. Even with a fully prunable mini-blockchain it can grow extremely quickly with large enough blocks. However in the future we may be capable of handling much larger blocks so we need a way of gradually changing it over time. A hardfork is obviously not very convenient. An automated readjustment system would be self-regulated and a much more seamless solution.