What about massive "spam attacks" of no-tx-fee transactions, is that possible? That wouldn't cost anyone anything.
AFAIK, the priority rules and some other safeguards prevent those attacks from disturbing the transactions that pay the minimum fee. Only legitimate but no-fee transactions will be delayed.
However, those low- or zero-fee attacks do overload the nodes and other programs that look at the queues. The last (prematurely aborted) stress test crashed blockchain.info and put all bitcoins ATMs out of service. It may have caused problems also for BitPay and other services that inspect the queues to accept 0-confirmation payments. The present test even broke
this site that was created precisely to monitor the queue s
The post you quoted also makes the assumption that all miners are producing full blocks when that is not the case. Many miners produce less-than-full blocks, even empty blocks, and so I'm sure that just compounds the issue even further.
Indeed, someone just computed the average of the actual size of mined blocks, and found that they are only 50% full on average, even though the queues have a huge backlog of fee-paying transactions. Part of the problem is the "hash stealing" shortcut that many pools use, that allows them to start (and finish) mining an empty block well before they can pull the information needed to fill it.
Thus the maximum capacity of the network is actually only 180'000 tx/day, or ~2.1 tx/s. The current traffic (excluding the stress test) is already 120'000 tx/day. So if it grows only 25% (30'000 tx/day more) , there will probably be recurrent traffic jams, during which the wait time for the first confirmation will be hours instead of minutes.
I am of the opinion that the answer to the block size debate is not 1 or 8 or 20 or variable, the ultimate solution will be one that address the issue of block size in a manner that hasn't been conceived yet.
I believe that there will have to be both a hike in the transaction fees and in increase to 8 MB. That would buy another couple of years, at least before the network saturates.