What I meant was that big spam transactions would cost them an amount of hashing power that they - if they ignored these transactions or give them a very low priority - could use better to find blocks faster and get an advantage over their competitors.
Well, saying that it would "cost them" differently is also incorrect. If you have two transactions:
1) native-to-native which is part of a big group of spam with X fee.
2) native-to-segwit or segwit-to-segwit which is a genuine transaction with a fee equal to X, it doesn't matter much for the miner. It costs them the same amount.
its taken years of debate and still no guarantee on moving the block size once.. do you honestly think moving to 1.2mb is going to benefit the network, and then have another few years of debating to gt 1.4mb..
There is no debate. I have already mentioned that this would be done with 1 hard fork, so the subsequent rises (1.2 to 1.4 to 1.6 and so on) would be hard coded.
if your talking about progressive blocksize movements that are automated by the protocol and not dev decisions per change.. then you are now waking up to the whole point of dynamics.. finally your looking passed blockstream control and starting to think about the network moving forward without dev spoon feeding . finally only took you 2 years (even if you think that hard limiting it at silly low amounts is good)
I am not strongly interested in hard fork proposals until I see someone coming up with solutions for the sigops problem.