Motivation of the "stress tests" now revealed: Coinwallet.eu has a wallet that computes the correct fee to get through their "tests".
http://www.ibtimes.co.uk/coinwallet-plans-bitcoin-dust-attack-september-create-30-day-transaction-backlog-1515981Note that they plan another mega stress test for September.
Someone should do a *real* spam attack on bitcoin, not like those stupid "stress tests" that use fixed fees. If BitcoinXT prevails and the block size limit is lifted to 8 MB in 2016, both "stress tests" and real spam attacks will become 10 times more expensive.
To do a real spam attack, you pick a goal percentage of transactions that you want to delay, say 50%. Then you start issuing spam transactions at such a rate and with such a fee that 50% of the legitimate transactions in the pool are kept out of the next block.
Typically, when a new block is mined, there will be 450 kB of legitimate unconfirmed transactions in the pool. To keep half of those out of the next block, it suffices to issue 775 kB of spam transactions, all with a fee F that is higher than the median of the fees in the pool. The next block, if it is full, will take your 775 kB of spam and 225 kB of legit traffic, leaving the other 225 kB on the pool. Then, you must issue quickly another 775 kB of spam with that fee F, and keep adding more spam, with increasing fees if needed, as more legit transactions arrive, so that the top 1 MB of the pool will include at most 225 kB of legit traffic.
The average capacity of the network is less than 1 MB every 10 minutes, because there are many empty blocks even when there is a backlog in the pool. Thus, on average, it may be enough to issue only 575 kB of spam every 10 minutes, rather than 775 kB, if you are able to guess the required fees exactly.
You keep doing that until your budget is exhausted. During that attack, a backlog of legit traffic will develop in the pool (mixed with some spam), growing by at least 225 kB of legit traffic every 10 minutes. If your budget is enough to keep up that attack for one day (144 blocks), the backlog will then clear ay the rate of ~300 kB every 10 minutes; so the legit transactions alone will take at least ~100 blocks to clear. The average delay for the transactions that had the bad luck of being below the median will then be ~20 hours (instead of the ~10 minutes of normal conditions).
The fee-adjusting tools that have been proposed by the Blockstream devs, to be used in the "fee market", woudl make this atack much cheaper. inevitably, some of yous spam will end up in the backlog, with fees that are smaller than most of the legit traffic there. So, instead of issuing new spam transactions with increasing fees, you could use Peter Todd's replace-by-fee feature to re-issue the spam of yours that is in the pool.
To foil this attack, everybody would have to raise their fees so high and so fast that the attacker will run out of funds after a few blocks. I am too lazy to compute now what would be a suitable Branson-level fee.
Another solution is for everybody to use a smart wallet that picks a fee that is guaranteed to be above the median of the fees picked by all other clients using that same smart wallet. But I think there may be some obscure technical obstacles to that approach.