--snip--
If the block size limit is lowered, the cost per transaction increases. There is the potential that transaction fees in total will increase more than the block size limit will decrease. So lowering the limit would increase total transaction fee revenue.[...]
In this case the network's hashrate will increase and it will be harder to maintain the attack. If the avg fee goes above 1% then the block size limit will increase in the next epoch.
If there were a situation in which bitcoin must have a dynamic block size limit, it would be superior to have the block size limit based on a sat/vByte basis. If the cost to include 200 bytes in a block becomes too high, the block size limit will increase, and if the cost to include 200 bytes in a block is too low, the maximum block size will decrease.
The problem with this proposal is that we don't know the real value of the fee, if the price of btc is high then the fee will be too expensive, if the price of btc is low then the price per vByte will be too low, we can determine a percentage but we can't determine btc's price.
Haha. I am the stupid one in the forum, I will never have better ideas to force out of my mind. But I believe I’m smart enough to know that everything that we thought are “good ideas”, they are actually not after 10 years of the Core Developers’ research and work on the protocol. If you are a developer, make a BIP, give all the technical details.
Didn't say any of that, I'm just observing that many of those ideas are not being pursued (or maybe it's just the lack of action since 2017). Building a BIP on my own is something I might consider...