Re: SegWit + Variable and Adaptive (but highly conservative) Blocksize Proposal
Mathematically, assuming an average block time of ~10 minutes, there are a maximum of ~104 difficulty adjustments over a 4 year period, so even if there was a .01 MB increase at every difficulty re-target (the chances of which are negligible), the base blocksize would still only be ~2.04 MB after 4 years.
saying 2.04 MB after 4 years conceals the fact that the real total blocksize would be 8.16MB when you include the signatures in the witness blocks, Segwit is a part of this deal you're proposing.
In reality it could take far longer than 4 years to reach that sort of size. I'm sure many pools will still be mining largely empty blocks just to grab the reward, so because of that and other factors there probably won't be an increase every time.
That's not convincing at all. Remember that the difficulty rarely drops, and we could see an explosion in mining growth when the real corporate money begins to flow into the mining industry.
All growth, BTC exchange rate, transaction rate growth, blocksize growth and hashrate growth act synergistically with one another, they all aggregate into a wider positive feedback loop. I realise that even this will have a marginal effect on the possible blocksize growth we end up with (say 1.04 MB per year + factoring in 0.2 MB max for the < 2 weeks per difficulty period), but that doesn't mean your conservative expectations were any more correct, just that they don't effect the overall outcome too much, which brings me to my next point....
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
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.