Re: SegWit + Variable and Adaptive (but highly conservative) Blocksize Proposal
I'm reasonably certain that the total blockchain size won't experience any dramatic growth as a result.
You're probably right. So why do it? We can be straight about the fact that 1.04 MB per year won't annoy the small blockers too much, but it won't satisfy the demands of the big blockers at all. Or is that why it's a compromise? Everyone's equally unhappy
Pretty much, heh. My hope is that all participants at least feel their voice is heard this way. With the two polar opposite camps screaming at each other, it didn't really seem like either side were actually acknowledging what the other were saying.
Lastly, and obviously, even if the maximum size increases, miner's don't necessarily have to fill it. They're still quite welcome to release <1MB blocks after an increase if that's their preference.
Again, we part ways here. If there is a breakdown in the growth paradigms of the technological factors that determine the upper limits of the Bitcoin's network capacity (i.e. median internet bandwidth, average storage space costs and average overall computing capabilities), then we'll be back here on bitcointalk.org du jour circa the year 2027, arguing about where and how the blocksize should stop, instead of how it should grow.
Infinite growth needs infinite resources, and I'm not noticing the solution to the infinite resource issue in this proposal. Maybe time will solve that, but that's one big maybe, and not an engineering approach at all. Wishing things away is bad engineering, there should be a qualified upper limit to round this proposal off, otherwise you can't expect it to be considered a complete proposal.
I wasn't aware that particular precedent had been set. BIP 100, 101 and 106 never specified an upper limit. While it's true the community didn't deem them viable proposals, they certainly didn't deem them incomplete either. This sounds like more of a personal preference on your part rather than a community standard of what constitutes "complete". If we do have to look at capping it off in future, then we can look at that. Any attempt at preempting a limit now is guesswork at best and also opens the door to future hardforks. Capping off would be a soft fork. I won't dismiss a cap outright, but I'd need more than just one person telling me it needs one. As per the OP, I do have a fairly strong aversion to arbitrary static limits, but then that's just my personal preference.