Quote from: CounterEntropy on September 14, 2015, 03:58:28 PM

Quote from: LiteCoinGuy on September 14, 2015, 11:28:41 AM

Quote from: Amph on September 14, 2015, 07:20:22 AM

Quote from: CounterEntropy on September 14, 2015, 12:04:25 AM

Dynamic block size limit is the best any day.

Check BIP 106: https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki

is this working in this way?

if we reach 2mb traffic the client change automatically the limit to two, if we reach 4mb the client change again to 4mb, etc...?

if this is correct and it working as intended, i think it's the best solution out there

but what is the limit? otherwise some miner could force the system to adapt 3 GB blocks within 1 year or so.

BIP 106 does not dictate any limit. It adjusts the block size max cap according to network demand. To force the cap to 3GB within 1 year and keep it there, one miner has to have majority hash power, with which he can easily do 51% attack. So, it is a most unlikely situation. But, even if it happens, the algo will bring down the cap as soon as the miner is out of majority hash power. It is a demand driven approach, just like difficulty.

Quote from: LFC_Bitcoin on September 14, 2015, 02:13:06 PM

I think block sizes should be increased as & when it is required. Maybe 2MB for a while & then when the network dictates it increase it again to 4MB & so on.

I think it's ridiculous to be thinking about 8MB & 20MB blocks now.

That is you invite frequent forks, which is most undesirable in a sustainable system.

You've just triangulated the truth. Congratulations!
With a few more clarifications we will almost get there.

Adjusting the limit according to network demand is a slippery slope, as miners are profit-driven. If it is economically viable for them to target higher bandwidth with larger blocks yielding more fees, they will definitely go there (in order to break even at least), while the rest of non-mining home-based full nodes (not explicitly incentivized in the current setup) protecting consensus rules with their sheer quantity (or mass) will be left biting the dust.

Over-protecting the network by selecting a smaller limit without a clear roadmap for further scaling, would indeed necessitate frequent debates and might as well melt the idea of the limit altogether. Peers will simply begin adjusting it all on their own, without listening to each other and the whole thing will spiral out of our hands.

Now, you see, that we managed to CounterEntropy

to a single static limit (agreed upon via consensus and firmly cemented in our perception of Bitcoin for at least 4-6 years), which is not too high and not too low (8MB will do) with a gentle yet quick enough schedule to achieve it.