If the 2-4-8 thing ends up being the idea that most people get behind, then I'll support it. But I'm still not sure I understand the fixation with whole numbers. Why not smaller increments more often? We don't necessarily need to double the number of transactions the network can support unless we see a massive surge in adoption. The main concern is jointly that we shouldn't hit a wall with regards to transactions and we shouldn't be too aggressive with the increases in case it jeopardises node decentralisation. Still hoping for some sort of happy medium between BIP106 and BIP100, where the limit is dynamic and only changes when the network demand (or lack thereof) is present and the miners agree:
The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain. Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often,
if needed. One possible route is to take the best elements of BIP100 and
BIP106. BIP100 only considers what benefits the miners and not the users. BIP106 only considers what benefits the users and not the miners. So neither is particularly balanced on its own. If we can find a way of allowing half of the "vote" to go to the miners and half to an automated, algorithmic vote based on traffic volumes, then we maintain some kind of equilibrium that should (in theory, at least) benefit the network as a whole.
Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig to:
raise blocksize limit by 12.5%,
lower blocksize limit by 12.5%,
or remain at current blocksize limit.
This vote, however, only counts for half of the total vote and the other half is determined by algorithm based on network traffic:
If more than 50% of block's size, found in the first 1008 of the last difficulty period, is more than 90% MaxBlockSize
Network votes for MaxBlockSize = MaxBlockSize +12.5%
Else if more than 90% of block's size, found in the first 1008 of the last difficulty period, is less than 50% MaxBlockSize
Network votes for MaxBlockSize = MaxBlockSize -12.5%
Else
Network votes for keeping the same MaxBlockSize
The 12.5% part is open to negotiation, some think 10% is more reasonable (i.e. BIP105). If every 1008 blocks is too fast, we could (for example) increase that to 2016 blocks, approximately every two weeks. Tweaks are inevitable, but I feel it's something that could work if it's not too complex to code.
