This problem is far worse if blocks were 8MB: an 8MB transaction with 22,500 inputs and 3.95MB of outputs takes over 11 minutes to hash. If you can mine one of those, you can keep competitors off your heels forever, and own the bitcoin network
Well, probably not. But thered be a lot of emergency patching, forking and screaming
And this assuming the initial optimizations completed to speed up Verification!
This means that If we hardforked a 2MB MaxBlockSize increase on the main tree and we softforked/hardforked in SepSig, we would essentially have up to a 8MB limit (3.5MB to 8MB) in which an attack vector could be opened up with heavy input and multisig tx which would crash nodes.
These are edge cases... but edge cases are what attackers use to disrupt the network.
Remember we have to design code to expect the worst and hostile intent, especially for bitcoin which has many extremely powerful adversaries. This is why I have a nuanced view of simultaneously supporting multiple implementations, the conservative approach from the core devs, and eventually increasing the block limit.
That is small-blockian FUD. (Rusty is a Blockstream employee, BTW.)
There is an easy fix for that problem: limit the number of inputs and outputs to a sane value. There is no real need to have more than (say) 16 inputs or 16 outputs. If one needs more, just use several transactions.
The problem is that the cost grows like N^2 for N inputs. Thus the cost for a single 256-input, 1-output transaction is about 256^2 = 65536 times the cost C for a single-input, single-outout one. The same effect can be obtained with 17 transactions with 16 inputs each. The total bytes will be only a bit more, and the validation cost will be 17 x 16^2 = 4352 times C, or 5% of the big one.
IIRC, BitcoinXT already has a limit on the number of inputs (a lot more than 16, but a lot less than 20'000) that solves that problem. That fix should be in BitcoinCore too; but I would not be surprised if Blockstrea blocked it too.