That would be the send to many problem we have been seeing on the blockchain.
This is where a attacker sends continuous micro transactions to spam the blockchain and it results in a bloated blockchain and it can seriously delay all transactions in the blockchain. Bitcoin and other coins have had to create a fix for this problem in the past.
Here is a quote from Bitcoin wiki regarding Bitcoin's weaknesses.
It is easy to send transactions to yourself repeatedly. If these transactions fill blocks to the maximum size (1MB), other transactions would be delayed until the next block.
This is made expensive by the fees that would be required after the 50KB of free transactions per block are exhausted. An attacker will eventually eliminate free transactions, but Bitcoin fees will always be low because raising fees above 0.01 BTC per KB would require spending transaction fees. An attacker will eventually run out of money. Even if an attacker wants to waste money, transactions are further prioritised by the time since the coins were last spent, so attacks spending the same coins repeatedly are less effective.
Many coins have had this problem it seems.
Here is a Dogecoin reddit thread about this problem.http://www.reddit.com/r/dogecoin/comments/1tc7ul/serious_shibes_we_have_a_dust_problem
This might affect the network greatly as hashing power and nodes are limited at this time.
I think this might be a Sybil attack in combination with dust attack and possibly kind of DoS attack which is serious.
An attacker can attempt to fill the network with clients controlled by him, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything completely isolating a node from the honest network can be helpful in the execution of other attacks.
This state can be exploited in (at least) the following ways:
The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.
The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks.
If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.
Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.
Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.
Looking for suspiciously low network hash-rates may help prevent the second one.
Bitcoin has implemented a lot of protection from these kind of attacks but Auroracoin is currently built on old Litecoin code so it's highly likely that these guards are not in place here making the coin more vulnerable.
I don't know if these attacks might have created the delay that we saw in the claims making the claims come through when the claiming site was offline but it might be worth considering. Someone with a better understanding of the blockchain and the core code than me would have to answer that though.
This clearly makes updating the coin to the latest Bitcoin core the highest priority we have.