It's not wrong, because it's not the entire solution. I forgot to add that you also determine fees by checking every 2016 blocks what the average fees per block were. Now miners can't manipulate the fee anymore because they don't know who will find the next block, well unless they unanimously decided to insert fees enough to raise the limit, something really hard to achieve since if just one big miner doesn't agree the rest would be paying him to raise the limit.
Is this software design by debate? Am I the design oracle which will only tell you when a design is no good, so you search for the solution by suggesting all the things which are not the solution?
Think a little harder on this. This fails because its costless and obviously in all miners interest to mine fake fees. Fees are paid to this block, not the next block, miners would pay fees to themselves and skew up the average. Your revised proposal is isomorphic to straight up having miners vote on it, which fails for all the previously discussed reasons.
Quote
I don't like this idea because I don't think enough fees would be collected to provide for adequate security. What if hashpower becomes so easy to increase that the relationship you set as a rule for block size limit being raised doesn't even beging to cover anything?
I don't like it much either, but not for those reasons... What was suggested there is proportional and limits the increase to be strictly less. Breakthroughs in the energy efficiency of POW will also result in increases in efficiency of verification (except perhaps POW ease due to a huge SHA256 break, but in that case we must hardfork to remove SHA256 from the merkle root). I said it's retarded to suggest it in Mikes scenario when there is no(or close to no) income. There are better ways to heat than to run a miner on a loss.
Okay, I missed that condition.