While I've always been a fan of BIP106, I'm starting to appreciate the merits of "proposal 2" a bit more now. Making it dependent on fees would definitely add an additional layer of security.
BIP 106 provides a way of slow max blocksize change, reflecting slow processes of adoption change, while my concern is how to cope with sudden significant increase in tx influx.
I believe both approaches could work in conjunction. In terms of the OP, BIP 106 could slowly change S0, while there could be another algorithm, similar to what is proposed in the OP, which could quickly, without any delay, increase max blocksize when necessary. Maybe even the term "max blocksize" becomes misleading with this approach. Blocks become elastic, like Meni Rosenfeld explains. There is an "unstrained" blocksize which can be regulated according to BIP 106, but we can "stretch" blocks, temporarily "inflate" them, when necessary.
The "sudden significant increase in tx influx" part is a tricky one, since there's no real way to discern between an attack on the network and an increase in legitimate usage. It's better if blocksize adjustments aren't too large in one go, as if someone did find a way to game the system, smaller adjustments would make the attack more costly to sustain and would give developers more time to detect and correct the problem before the attacker did too much damage.
It's conceived that blockspace exceeding S0 can only be 'bought', it's never free. Space purchases in any two different blocks are completely independent. I.e. if users bought additional space equivalent to S0 in block N, that doesn't affect block N+1. N+1 still has S0 free space, any additional space must be payed for. The more space users buy, in any given block, the more expensive it becomes. That doesn't affect other blocks.Relevant thread in case u r interested - https://bitcointalksearch.org/topic/bip-106-dynamically-controlled-bitcoin-block-size-max-cap-1154536
I already started reading it.BIP 106 provides a way of slow max blocksize change, reflecting slow processes of adoption change, while my concern is how to cope with sudden significant increase in tx influx.
I believe both approaches could work in conjunction. In terms of the OP, BIP 106 could slowly change S0, while there could be another algorithm, similar to what is proposed in the OP, which could quickly, without any delay, increase max blocksize when necessary. Maybe even the term "max blocksize" becomes misleading with this approach. Blocks become elastic, like Meni Rosenfeld explains. There is an "unstrained" blocksize which can be regulated according to BIP 106, but we can "stretch" blocks, temporarily "inflate" them, when necessary.
The "sudden significant increase in tx influx" part is a tricky one, since there's no real way to discern between an attack on the network and an increase in legitimate usage. It's better if blocksize adjustments aren't too large in one go, as if someone did find a way to game the system, smaller adjustments would make the attack more costly to sustain and would give developers more time to detect and correct the problem before the attacker did too much damage.
It's also important to realize, that under optimistic scenario, if Bitcoin adoption continues to grow, and hopefully Bitcoin economy becomes comparable in size to present USD or EUR economies, fees must remain low (i.e. total fees in a block must be much smaller than block subsidy) for years and maybe even decades from now, because of mining energy consumption.
