I don't find this convincing. A miner is driven to maximise the value of the network (considering both the short and long term) but also to drive other miners away, lowering difficulty. Might it be that BIP100 conceals a tragedy of the commons: miners each vote in a way that inadvertently hurts decentralisation despite their wanting to maintain decentalisation.
It is true miners may also want to drive other miners away and lower difficulty, however there is no clear voting method in BIP100 which achieves this, in my view. I can think of three strategies which could attempt to do this:
1. A large well connected miner voting for larger blocks, such that smaller miners cannot compete with propagation.
Response - The upper bound in BIP100 should defend against this.2. A miner with large cash reserves votes for smaller blocks, the plan is to limit bitcoin capacity and then reduce utility and therefore the exchange rate. Other miners without cash reserves then exit the industry and the miner with large cash reserves take short term losses before voting to increase the limit again.
Response - This attack seems extremely unlikely and a long enough voting period makes this unfeasible.3. The reverse of 2, voting to increase the limit to drive down fees and force other miners to exit the industry.
If you have another voting strategy which could drive down the difficulty, please let me know. In my view a long enough voting period will make these strategies unfeasible.
This is completely backwards. Block size reflects demand, the block size limit relates to supply. If, for example, the world wants 1000 Bitcoin transactions per second but technology is such that, in a well-decentralised network, it is not possible to provide more than 50 transactions per second, then the block size limit should hold us to 50 transactions per second.
The reasoning in my comments are mostly about economics and incentives, not technical limits. BIP100 should have an upper bound, which reflects technical considerations like propagation time, storage costs ect
More critical would be an upper bound. I would be more comfortable with BIP 100 if it had BIP 101 as an upper bound.
I agree an upper bound may be required for technical reasons. The points I made above are mostly the economic reasons for BIP100. The current 32MB limit would be fine, although I would be happy to compromise and have BIP101 as the upper bound, if this ensures BIP100 gets more support.
I initially thought BIP100 was pretty good too but now after some serious thought I am convinced miners will ALWAYS vote for bigger blocks. It simply gives them more flexibility. They can always soft limit whenever they want.
I don't think this is right. Miners may vote for smaller blocks to prevent other miners making larger blocks. Sure each miner has the flexibility to soft limit down their own blocks, but they can't force others to do so. Understanding BIP100 is about evaluating the incentive differences between all the miners and each specific miner.