Yes, we have effective spam/bloat countermeasures. That's why at present most blocks aren't full.
And Bitcoin certainly sees sudden spurts in adoption. Thus my concern with the ultimate form of bloat: widespread actual usage.
We need to understand how the system reacts to heavy actual usage.
Will anything break, or rather, what will degrade/break first? How will the markets react? What can be optimized and/or substituted given proper incentives such as the removal of free riders and their subsidized blockchain space?
It's nice we agree on a geometric increase, but wouldn't it be great to have actual data on which to better determine the optimum initial increase and eventual rate of increase?
Before changing the max_blocksize constant, we should know what happens to the BTC function at (and over) the 100% limit of the tx/block variable.
And Bitcoin certainly sees sudden spurts in adoption. Thus my concern with the ultimate form of bloat: widespread actual usage.
We need to understand how the system reacts to heavy actual usage.
Will anything break, or rather, what will degrade/break first? How will the markets react? What can be optimized and/or substituted given proper incentives such as the removal of free riders and their subsidized blockchain space?
It's nice we agree on a geometric increase, but wouldn't it be great to have actual data on which to better determine the optimum initial increase and eventual rate of increase?
Before changing the max_blocksize constant, we should know what happens to the BTC function at (and over) the 100% limit of the tx/block variable.
We do have some data on what happens when blocks hit a limit, as they've hit a soft limit at 250 KB before. It wasn't an extended experiment, but it did give us an idea what happens at the outset. What happened is that people had to wait a few blocks to get a confirmation, which was inconveniencing people.
Doing a longer experiment on block subsidy would provide with even more data, and create incentives to come up with off-chain solutions. However, I don't think it's wise to run such an experiment, because it comes with some pretty big risks. Here's why I don't think now is the time for a block subsidy experiment:
1. it could turn a lot of people away from Bitcoin as they have difficulty getting txs to confirm.
2. off-chain solutions might not get invented. We actually don't know if there are adequate off-chain solutions for scalability. We hope there are, but it's possible they are all inadequate. If that's the case, then during the entire block scarcity experiment, users would be left without a way to transact in bitcoin
3. due to 1 and 2, it could hurt Bitcoin's momentum. Deploying a technology and achieving mass adoption is about maintaining momentum. Eventually a technology will fade from the public consciousness, so it's important the opportunity to achieve mass adoption is seized. Further, governments are creating new legislation all the time put Bitcoin under greater restrictions. Mass adoption is the best defense against new legislation, as we saw with the internet.
4. we have plenty of opportunities to conduct scarcity experiments when we actually need to limit block sizes. There will come a time when Bitcoin blocks simply cannot get larger without harming decentralization. At that point, blocks will have to be artificially limited in size, and then we will get all of that experimental data you want on how a system behaves under scarcity.
In conclusion: at 1 MB, 4 MB, or 5 MB, is absolutely not the right time to conduct a block subsidy experiment. Additionally, we don't need a hard limit to run a scarcity experiment. A hard limit is a crude and dangerous way to limit block space, because if we find the experiment is harmful, a hard limit is difficult to quickly remove. Experiments with block scarcity should be done with soft limits, not with unchangeable protocol rules.