From the account 0x969837498944ae1dc0dcac2d0c65634c88729b2d, you will see that there were 277 attack transactions. From the listing, you will see that there were 9 failed transactions on the last page. (There were a few early in the attack as well.)
The last successful transaction before the set of 9 failed transaction in block 1720231 had a gas usage of 2890937.
The first unsuccessful transaction in the set of 9 failed transaction in block 1720316 had a gas usage of 4273000. This block had a gas limit of 4712388 and a gas usage of 4710819.
From this information and the gas usage being close to the gas limit in blocks 1720337 to 1720426 containing the series of 9 failed attack transaction, I would guess that the other transactions on the block used up the block's gas usage towards the block's gas limit, causing the attacker's transaction to fail.
However, I could not find any transactions (from my brief look) generated by the friendly's spamming attack using the code listed in What does TheDAO counter-attack by spamming actually do? (suggested by Stephan Tual):
for (var i = 0; i < 100; i++) {
eth.sendTransaction({from: eth.accounts[0], gas: 2300000,
gasPrice: web3.toWei(20, “shannon”),
data: “0x5b620186a05a131560135760016020526000565b600080601f600039601f565b6000f3”}) }
}
And looking at the blocks around the time of the series of 9 of the attacker's failed transactions, there were quite a number of blocks with 0 transactions, e.g. block 1720318.
The other attacking account 0xf35e2cc8e6523d683ed44870f5b7cc785051a77d had only one failure early on, so the transactions from this account were not affected by the friendly's spamming transaction.
Conclusion:
My results are inconclusive.
- Only a small portion of the attacker's attacking transactions failed and these may have been caused by other transactions filling up the block's gas usage.
- And there were some blocks with 0 transactions around the time of the failure.
- And the was no sign of the friendly's spamming transactions around the time of the failures.