-snip-
Also, by "buying time" (with which I totally agree) we might bloat the blockchain right now, making it hundreds of GB whereas a much better solution could be implemented in the future. It is a compromise.
I think that this is wrong and it is not a compromise. We might actually contribute 0 additional GB to the blockchain before other solutions kick in. Without the increase we can't really be sure if the network will be able to handle everything.
Here are the potential outcomes of what might happen (we're disregarding everything other factors/events that could occur):
1) We don't increase the block size; blocks get capped before other solutions are ready = problems
2) We increase the block size; blocks don't go over 1 MB (yet) meaning 0 (zero) additional increase of GBs to the blockchain (because of the increase)
3) We increase the block size; blocks go over 1 MB resulting in normal transaction behavior and (hopefully) enough time for other solutions.
I see what you mean, however if case 2 was indeed a likely possibility, we wouldn't be here discussing this. More likely is that blocks would need to be larger and some solution is indeed greatly needed. Hence we can keep the block size, and buffer transactions that will eventually either go through (or not) or apply the solution that we think is best at the moment. Which
could potentially cause problems or rather inconveniences down the road.
Also, by "buying time" (with which I totally agree) we might bloat the blockchain right now, making it hundreds of GB whereas a much better solution could be implemented in the future. It is a compromise.
TBH I the blockchain is already bloated to the point where pruning is fast becoming a necessity, the .bitcoin directory is at 45 GB with txindex, this means we are already beyond the realm of the "Cheap VPS", we will soon have left the realm of cheap EMLC SSD drives and flash storage, and within a year (even with no blocksize increase), we will likely break 100 GB.
However once you prune the blockchain, keeping a full transactions history for the last days/weeks, and only keeping track of unspent outputs beyond that, the storage requirements are not so scary anymore.
With pruning, you could easily handle 20 MB blocks with the same amount of storage that is needed now. You would probably save bandwidth as well, FWIW my full node is using more bandwidth "seeding" historical blocks than to propagate live transactions and recent blocks.
Once pruning takes over, I wonder what that will do those that use the blockchain as a ledger for non-blockchain stuff. I guess they will just have to burn coins or face their tx be pruned and forgotten.
I only have a laptop at the moment and this was the reason I stopped running a full node a few months ago. I simply didn't have that 30-40 odd GB of space on my small HDD that I could sacrifice. If I get the chance (=money) I might get an external HDD and set up my Raspberry to support the network.
Eventually, some people or servers have to keep a full blockchain, otherwise (I think) the purpose of the blockchain would be partially defeated. On the other hand, for lightweight clients, yes sure we can choose to look at only the most recent part of the chain. (Isn't roughly this what happens in some lightweight clients?)