Did the spamming counter-attack on The DAO attack work to slow down the attacks?

Question

This question was asked in the comment section of What does TheDAO counter-attack by spamming actually do? (suggested by Stephan Tual).

Background links:

• The attacks used a recursive call vulnerability as described in What is a recursive calling vulnerability?.
• You can find a list of the accounts used in Which accounts are involved in mounting the recursive call vulnerability attacks on The DAO?.
• You can find the period when the attacks occurred in Is there any way to determine how long it took for the DAO attacker to deploy the attack?.

Did the spamming counter-attack on The DAO attack work to slow down the attacks?

Answer 1

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.