Confirmed - and thank you:)

LOL - hopefully we upgrade ourselves to Skype levels soon enough;)

2014/08/24 Monero Blockchain Spam Attack - Post Mortem

Part I

A slightly deeper analysis around the transactions and the timeline will come out in part 2 tomorrow, along with the Monero Missive (delayed to give us time to focus on this priority;)

On 2014/08/24 a spam attack was launched against the Monero blockchain. Up to that point, Monero had a relatively low fixed fee per transaction of 0.005 XMR (under 1 US cent per transaction). This allowed the attacker to broadcast extremely large transactions every 5 seconds.

For the most part, the network worked as expected. The dynamic block size limit allowed the max block size to grow, and transactions were broadcast without incident. However, the (relatively) slow expansion in the median block size, among other things, lead to some transactions taking some time to confirm. This is not the usual turn of events - normally an increase in usage occurs over a couple of days in a best case scenario (Monero is featured on Dr Phil and Oprah, and every Monero user gets a whale once they check under their seat). At its worst, there were ~400 transactions in the memory pool that were waiting to be confirmed. The sudden, sharp, drastic increase means that the network needed to adjust, and in the interim some transactions took anything from a few extra minutes to an hour longer than usual.

Let's look at the actual effect on the blockchain:



From our average of around ~1750 transactions a day, the network spiked to 3255 transactions on the day of the attack - an 86% increase! Nonetheless, the network survived and handled it quite well.



Block time should average around 60 seconds. As you can see, there was no drastic change in our average daily block time, indicative of the network's robustness as it sought to maintain the 60 second average.



Blockchain growth over August was 6.684mb per day. Because of the attack, blockchain growth over the past two days was 20.326mb (23rd) and 15.05mb (24th). This is a net effect of 13.642mb extra + 8.366mb extra = 22mb more than average over the period.



As a final note of interest, you can see the minor dip in yesterday's block reward, as the block penalty kicked in to prevent too many large blocks being created.

Within the space of about 4 hours we had finalised and deployed a temporary fix that ramped the fee up. Thanks to the hard work and availability of pool operators and exchange operators on a Saturday afternoon/evening, we were able to get a large enough portion of the network to shift over to incorporate the change. Those pool operators that were unavailable in the wee hours of Saturday evening picked up the change on Sunday, and as of Sunday morning the network has recovered completely, bar 22mb of extra unnecessary transactions.

The ramp up to 0.1 XMR fees stopped the attacker dead in their tracks, and gives us a bit of time to regroup and finalise the changes we were making that will permanently prevent this in future.

I think the point they're making is that Bitcoin has 5.5 years of development, we have a couple of months. It "feels like Bitcoin in 2010" because it's the wild west, rough and raw and unknown and hard to use. I'd hope that in the next 3 or 4 or 5 years the Monero landscape will be vastly different;)

I'm seeing 32mb physical RAM, 5.82gb virtual, on my Macbook Air (that only has 4gb RAM). Your OS *should* do really good memory paging to virtual memory *if* you have sufficient VM configured. I'm not sure if Windows is super bad at this, but with OS X, as it is currently configured on my entry-level Macbook Air with 4gb RAM, I can get up to ~20gb RAM usage without getting much past the 32mb physical RAM used.


See above - virtual memory isn't the same as physical memory. If you're adding physical RAM to keep up then your OS is paging really badly.

HOWEVER...we are pushing ahead with the embedded database as quickly as possible. It's an incredibly involved and intense change, due to the consequences and edge-cases that may be encountered, but we are pushing as hard as we can to get it done as quickly as we can.

If everyone had that attitude then nobody would update. We'd all be sitting around "wait network make update".

It's much worse to wait in an emergency soft-fork situation, because you simply do not know what danger you are putting yourself and the rest of the network in. Incidentally, every other pool discussed it with me or in #monero-dev, and once we explained the situation they changed over immediately without waiting.

22mb more than the August average.

Yeah but hopefully they'll be ok not needing to send $1.85 around for the few weeks we need to roll out a permanent fix:)

We already did and the network was back to normal as of ~16 hours ago:) Emergency fix was built, tested, and deployed by major pools and exchanges within 6 hours of noticing the attack.

It shouldn't, simplewallet doesn't touch either of those files. When you start the daemon again after removing these two then they'll be recreated; p2pstate.bin is the daemon's peer lists, and poolstate.bin is the transaction mempool that it'll receive once it syncs up.

No there hasn't - they're going to be irregular and only when we have sufficient movement to warrant another developer event. There are updates in the Missives since then, they're linked in the OP:)

You need to watch this: http://vimeo.com/90127834

Multi-national corporations are among the very first in line to adopt a technology that prevents their competitors, the government, and external auditors from observing their accounts on the blockchain. The criminal or black market is a drop in the ocean compared to MNCs. They are craving a way to surreptitiously move funds between continents to tax havens in a way that does not require huge forex hedges.

That having been said, I can fully agree with your last point about association - MNCs will want to use something that does not sound like they're inherently doing something illegal. They're unlikely to have line items in their quarterly income statement that contain the words "dark", "teleport", "stealth", or "cloak" unless the corporation in question is DARPA:-P

There is no discussion, I've asked you to present a single fact. You have yet to present a fact. You're presenting an opinion.


Again - not a fact. A fact is something indisputable as it is either directly observable or provable. For example, I could say "TaunGawk's opinion is irrelevant because it is clearly a sockpuppet account that was created a mere 4 hours ago." That is a fact, verifiable by observing your profile page coupled with the nonsense you're posting.

Because as a cloud user I don't want my personal data stored by a reputable company, or as a business we don't want our collaborative data stored by a business with whom we have an SLA and whose sole job is the safe storage of data, we want it spread out across random hard drives, right? Or better yet - stored on the hard drives of tens of thousands of computers infected by a botnet, where the destruction of the botnet means the destruction of every redundant copy of my data. Sounds like a great idea!

There's also this: http://nakamotoinstitute.org/mempool/appcoins-are-snake-oil/

There were some concerns in another thread that it could give Bytecoin the ability to use debug commands to get an overview of the network. Whilst we have already audited this part of the code and determined this is not the case, we felt it prudent to zero the key out for the moment so as to allay concerns.

Yep, it's not my first time on the merry-go-round;)

How will NEM make all altcoins obsolete? Saying it as a statement of fact, without presenting any evidence to support it, is silly. You can say "in my opinion" or "I believe" if you want to spew unverifiable nonsense.


This just in: carrots debunked as inferior to oranges! Also, where did this "debunking" take place?

None of the other pools are using your patch, nor are any of them reporting being "broken".

Your patch breaks the consensus network because it does not prevent malicious nodes from constantly pushing bad transactions by cutting them off. An attacker can spin up 50 ec2 instances and broadcast nonsense transactions (20kb transactions filled with random data) at you at a rate of tens of thousands a second. Because you're not disconnecting their connections, you will burn CPU time verifying the transactions. Even though you aren't relaying the malicious transactions, you are creating a trivial attack vector for someone to take your pool and any nodes that use this patch out of commission.

This patch is bad for you, bad for the network, and fixes an imaginary problem that does not exist.

We'll have a post-mortem later today