|
ATguy (OP)
|
 |
September 17, 2015, 11:18:47 PM
Last edit: September 18, 2015, 12:04:14 AM by ATguy |
|
Here are rules:---------------------------------
Maximum block size is set to 1 MB from first block, and by default (if miners dont vote for increase, keeping or decrease) maximum block size is doubled at every block reward halving (210000th block, about 4 years).
Miners can vote in every block with options for setting next maximum block size:
- halve, maximum block size = (maximum block size / 2)
- double halve, maximum block size = (maximum block size / 4), if not enought votes for this option it counts for halve as well
- keep current maximum block size
- increase, maximum block size = (maximum block size * 2). No vote means this default option
- double increase, maximum block size = (maximum block size * 4), if not enought votes for this option it counts for increase as well
At every block reward halving (every 210000th block), set new maximum block size based on votes in the previous 4 years (210000 blocks) (do not apply if emergency voting succesfully set new maximum block size in any of the previous 210000 blocks, see below). Whatever of the three options (decrease, keep, increase) has most votes, it define new maximum block size. If no option has most votes (unlikely but possible), the new maximum block size is the same.
Emergency voting (firstly evalued = has priority over regular block reward halving voting every 210000 blocks): the 4 years is divided to 8 half years (26250 blocks), and if any of the three options (decrease, keep, increase) has over 103% - (number of half years * 4%) votes at the end of any 8 half years blocks (every 26250th block), apply new maximum block size (where number of half years is between 1 and 7 (evaluted from 1 to 7), and only from maximum block size was successfully set by voting (emergency or 4 years). To be backward compatiple from 1st Satoshi mined block, emergency voting is enabled from the next half year period if first vote is put in block (not the default, no vote = double max block size)
Maximum block size is limited by 64 integer, it can be set between 0 and (2^64)-1 bytes
---------------------------------END
It means current maximum block size would be 2MB (since block 210000) and next year (420000th block) 4MB (unless emergency voting successfully set new max block size).
One example to make things clear: Lets assume at block 420000, new max block size is set to 4MB and up to block 446250, 98% or 25725 voted for double halve, it is not enought because over 99% or 25988 votes for one of the three options (decrease, keep, increase) are necessary in the last 26250 blocks. Lets say 95% (24938 blocks) vote for just halve in the next 26250 blocks. Emergency halving is evaluted at block 472500, it needs over 99% of the last 26250 blocks which it does not have or over 95% of the last 52500 blocks which halving max block size meet this condition (25725 + 24938) > (52500 * 0.95). So max block size is set to 2MB from block 472501. Next emergency voting cannot use the previous 24938 votes for halving maximum block size, because it evalute only half year periods since new max block size successfully set by any voting. And at next regular block revard halving, block 630000, 4 year voting is not evalued because emergency vote was successfully applied in last 210000 blocks.
The reason for this proposal is I think it is better to choose final solution and do not hope in future this drama happens once again. I believe miner voting is good mechanismus for voting, I support Bitcoin with about one milionth of total hashpower, about 30 GH/s so I feel my vote might be fair considering the number of Bitcoin users (I do not blame only big farms will set the max block size because any small folk like me can support little Bitcoin hashrate and have fair vote for not much electricity spent).
The BIP100 has problems: no way under 1MB and over 32MB, and maybe limit inreased little later, but what if we will need much bigger max block size sonner? The BIP101 is very predictable but what if it is too big max block size, and the folks saying smaller sizes (few MB, or even under 1MB) will be optimal in future...
I preffer bigger block sizes like BIP101 but I might be wrong now and future shows smaller (or small sizes) are better - so I preffer flexible solution where in future the max block size can be set to many GB or under 1MB, but not risking hard fork in future anymore and splitting Bitcoin userbase - because this is the only value Bitcoin has.
|
