Quote from: Klestin on June 23, 2015, 04:38:58 PM

At first I thought you were being alarmist, but I came to the conclusion that you are absolutely correct once I realized as you did that:

I'm picking up on the sarcasm so let me address your comments:

Quote from: Klestin on June 23, 2015, 04:38:58 PM

- Increasing the block limit to X MB guarantees that every block will be exactly X MB

Agreed. Just like now where most blocks are 20-30% full we cannot assume that transaction volume will automatically fill the available block limit. Like Gavin and Hearn, I think it is prudent to prepare for this possibility beforehand whether it is caused by an attacker "testing" the network or wide scale adoption. Thus one should test for and understand the tradeoffs with all the available block being used to prepare for it.

Quote from: Klestin on June 23, 2015, 04:38:58 PM

- Bandwidth is a limiting factor right now, since 1MB barely makes it over a 14.4k baud modem in 10 minutes, and that's the best we now have

Bandwidth is fine right now, but there are other considerations to consider like miners concern of propagation time (some are already purposely limiting or not including transactions for a slight edge), running a node over TOR, and I have shown that historically network bandwidth hasn't scaled at the same rate of what is being proposed.

Quote from: Klestin on June 23, 2015, 04:38:58 PM

- Miners have absolutely no control over block size whatsoever, and no method (such as transaction fee policies) to decide which transactions to include

Miners ultimately decide what the limit to set will be as they can choose to include transactions or not even if developer increase the block limit. My concern with this is the same concern I have with Garziks proposal. The fact that 5 Chinese companies control 60% of the hashrate and can set the limit with or without any developers agreeing concerns me. I would be much happier giving miners more control if the hashrate was more distributed but we are a long ways off from that at the moment.

Quote from: Klestin on June 23, 2015, 04:38:58 PM

- This proposed code change is permanent and can never ever be revised based on future facts

Sure , we can always switch it back with another hard fork... but why not come to consensus on a proposal that is best for the community and properly tested to avoid the negative PR and a few more years of work debating and testing.

Gavin Just submitted the BIP a couple days ago.... so its still early on the testing . We should probably test his suggestion on a testnet under various scenarios before we agree or disagree with it. Initially, I don't think it is a wise proposal, but I am certainly open to my mind being changed with the right evidence.