nearly entirely agreed. the one quirk is if you are going to run arbitrary anonymous smart contract code and aim to support high-value transactions. because y

nearly entirely agreed. the one quirk is if you are going to run arbitrary anonymous smart contract code and aim to support high-value transactions. because you can only get "nearly optimal" it's always possible to rig the system into a worst case. and if you promise low-low fees all the time that isn't expensive to do. here an attack against the approximation algorithm is an economic attack. you cannot attack approximations in a normal scheduling system like this of course. all of this is resolved if you do something as you say and add a defense mechanism (i.e. rapidly escalating fees or brownouts) when "near optimal"!="good enough."