Quote from: DannyHamilton on August 19, 2015, 03:25:09 PM

If you are talking about writing the code so that it automatically increases, then the problem is that any malicious actor that wants to expand the limit VERY quickly could just make sure that ALL of the blocks that they mine are completely full every time (by filling it with transactions that pay no fees and send bitcoins from themselves to themselves).

If you are talking about creating a new hard fork release every time, do you really want to go through this messy debate over, and over, and over, and over every time the block needs to be expanded again?

I figured that would be the reason not to do it automatically. But I don't see the problem doing it manually.

Why would it be a new hard fork every time the size is updated? If the market needs it, ie enough blocks are above 0.5MB, time to update to 2MB.

Wouldn't it just be a normal update?

Quote from: gmaxwell on August 19, 2015, 03:25:54 PM

Quote

Wouldn't doing it this way increase the block size whenever the market needs it to?

Needs to be increased is tricky. The natural and necessary state for blocks is nearly full; defining need is hard. Near-universally agreed to be good to increase would be better, but people are sensibly worried that it would be held back by unreasonable people and so they are unwilling to take that risk.

Quote

Ex, when it reaches 0.5MB, raise it to 2MB. When it reaches 1.5MB, raise it to 3MB.

That would completely undermine the existance of transactions fees, which are the only long term security arguement we have. It would also allow the system to slip into arbritary amounts of centeralization if those increases were really guarenteed... because it could get to a point where no one but a few api providers bothered to run nodes. Sad

Are these issues also relevant to 8MB blocks?