 |
February 21, 2013, 07:27:36 PM |
|
Here's a hard forking idea to consider:
Instead of having a single value for MAX_BLOCK_SIZE, have two values. The current value, and a "proposed new value." The proposed new value could be 5% larger than the current value (the percentage is a baked in constant). Let's call this MAX_BLOCK_SIZE_NEXT. Now we add a rule that says 8% of blocks mined can have MAX_BLOCK_SIZE_NEXT as the limit instead of MAX_BLOCK_SIZE. An oversized block is accepted if it would not push the percentage of oversized blocks since the last adjustment over 8%. The value 8% is a baked in constant. Miners don't have to produce oversized blocks if they don't want to (but they will have to accept them, since this is a hard fork).
This change will have two effects:
1) We will have an indirect voting system of block size increases. It would be possible to simply look at the blockchain and measure the percentage of oversized blocks. As the percentage approaches its maximum, we can assume that there is increased interest in raising the block size.
2) It is possible to study the effects of a block size increase on transaction fees before committing all newly mined blocks to the new size. Only 8% of newly mined blocks would be oversized.
If we add a voting system like I wrote about in one of my earlier proposals, nodes now have an automated way of looking at oversized blocks and making a decision on whether or not the result is beneficial to them. The choice of yes/no vote to increase the block size can now be implemented in client code.
|
