Post
Topic
Board Development & Technical Discussion
Re: How a floating blocksize limit inevitably leads towards centralization
by
misterbigg
on 21/02/2013, 07:47:54 UTC
I don't know that I'd agree that a 1% change per difficulty adjustment is going to be enough.

All of the baked in constants are of course subject to tuning before final implementation. I used 90% and 1% as examples.

But remember that an increases in the blocksize translates directly into an increase in the minimum bandwidth requirements. Do you really want the minimum bandwidth requirement to double in one year? Even at 1% that still means that with a steady stream of successful votes, the minimum bandwidth requirement will increase by 12% per year. That's a lot.

Even a one time adjustment of the maximum block size to 2 megabytes would raise the bandwidth requirements to 3.4 Mbps. You're okay with this? If implemented today (assuming there was sufficient transaction volume) it would certainly preclude a large body of independent miners. Myself included (if the Jalapeno ever ships).

The penalty for increasing the maximum block size too slowly is that miners have large fees for a while. The penalty for increasing it too quickly is a loss of network hashing power and a centralization of mining power. Better to be conservative and adjust slowly.

...
This is such a contrived situation that I have to reject it as a strawman argument.

It is not contrived, it is precisely what would happen if the minimum bandwidth requirements were jacked up by a factor of 100 (which happens when you increase the maximum block size to 100 megabytes). I think he's just explaining it in terms that a non-technical person might understand.