Repost from Jameson Lopp MAR 13, 2021 : “A History of Bitcoin Transaction Dust & Spam Storms” The full report and all related findings are available on the official website of Jameson Lopp blog.

A historical analysis of spam attacks conducted on the Bitcoin network.

A historical analysis of spam attacks conducted on the Bitcoin network.

A well known feature of Bitcoin is that if you want to send money, no one can stop you from creating a valid transaction and broadcasting it onto the network. The flip side of this feature is that you can't stop anyone from sending money to you.

A well known feature of Bitcoin is that if you want to send money, no one can stop you from creating a valid transaction and broadcasting it onto the network. The flip side of this feature is that you can't stop anyone from sending money to you.

You may be wondering "why wouldn't I want someone to send me money?" Due to the scarcity of block space and fees related to this scarcity it can actually become an economic burden that costs more to spend than the value you received; naturally this is quite annoying to manage.

How does Bitcoin address this issue? Node implementations have a concept known as the "dust limit" which is meant to discourage malicious parties from sending infinitesimally small amounts of bitcoin that would cost more for the receiver to spend than the value of the created output. Here's what Bitcoin Core's documentation has to say:

Why would someone want to send dust?

As a developer who has been building Bitcoin wallets for many years, whenever users get a drive-by dusting it seems they always assume it's the last point. There is a strong narrative of "dust attacks" being an attack on privacy, but I've yet to come across convincing evidence that blockchain analytics companies engage in these tactics. In fact, analytics companies have gone so far as to explicitly state that they do not engage in this behavior.

CoinDesk reached out to Chainalysis and CipherTrace to ask if they use dust in their analytics. Both companies denied using this technique, though Chainalysis Manager of Investigation Justin Maile added that dusting is “more often [used] by investigators” to trace illicit funds. Maile continued that exchanges may use dusting to trace stolen funds following a hack.

I tend to believe that claim because I doubt the benefits are worth the cost; after all, the heuristics used by analytics companies (such as cluster analysis) work pretty well without the need for additional transaction inputs. Wallet software in general does a pretty good job (unfortunately) of linking together the funds managed by a wallet over time as a user consumes and creates UTXOs. As such, if you receive some dust and a lot of other people are also getting dusted, I believe this is unlikely to be a targeted attack against your privacy.

Blockchain Analysis

I wrote this script to get an initial sense for the historical volume of spam storms. It's worth noting that "spam" is in the eye of the beholder. From one perspective, there is no such thing as a spam bitcoin transaction - if it's valid and it pays an appropriate fee, a transaction should get confirmed. So... what transaction attributes am I categorizing as spam? I'm considering it suspicious if a transaction has all of the following:

Unlike my previous analysis of block timestamps that I was able to run in 5 minutes over 670,000 blocks that are only 80 bytes each, this script has to look at 620,000,000 transactions - hundreds of gigabytes! It actually ends up being far more than that due to having to also look up transaction input values in order to calculate the transaction fee paid. My first run took 24 hours to complete on my laptop. By the time it completed my process monitor noted the script had read nearly 2 TB of data from my node.

After the first run I started manually checking some of the transactions that were categorized as spam and realized that a lot of them were clearly coinjoins. After applying additional filtering logic to throw out transactions with many inputs I got the script runtime down to 16 hours. I've pasted the raw data from my various runs of the scripts in this spreadsheet.

Charts!

The resulting data sets are fairly noisy, especially when viewed on a linear Y axis. Switching to log scale helps show when abnormal events occurred.

Dust / Spam Transactions Confirmed per Block

The raw transaction chart paints the clearest picture of when obvious spam storms occurred. You can see that there's a nearly constant undercurrent of a handful of spammy-looking transactions throughout the blockchain - these could be perfectly legitimate mass payouts from various services. Every once in a while there will be a noticeable spike of an order of magnitude or more.

Block Space Consumed by Spammy Transactions

Looking at the spammy transactions in terms of block space provides an interesting perspective as we start to see vertical and horizontal striations. While it's just a gut feeling that would require deeper analysis to gain higher confidence, my suspicion is that vertical striations are entities that are spamming at high intensity for a short period while horizontal striations are entities that are spamming at low intensity over long periods of time.

What's clear from this chart is that in terms of bitcoin-denominated output value, it's getting more expensive over time to create spam UTXOs. This is a result of transaction relay rules being tightened over the years. Interestingly, the blocks at the bottom of the chart in the ~470,000 height range were actually created during the storm around height 310,000 but not confirmed until years later. We'll dig into that phenomenon in a bit.

This chart of transaction fees deceptively shows the opposite trend as the chart of spammy output values. You might think that it has become cheaper to spam the network. Rather, what this chart shows is that there are fewer spammy transactions that are paying for less block space as a result of it becoming more expensive to spam the network. Also, remember that the bitcoin exchange rate has increased by orders of magnitude over the course of this chart.

Next let's dig into some of the distinct spam storms that we can identify throughout history.

September 2011 Single Satoshi Spam

From blocks 143869 to 143890 there were a bunch of transactions, each with 102 outputs of a single satoshi each. This storm consisted of:

April 2013 Alphabetized Outputs

Around block 230,209 there was a burst of transactions with unique attributes. Each transaction had 85 outputs, each output value was a multiple of 330 satoshis, and the output addresses were in alphabetical order - they had clearly been mass loaded from some list

Around block 231,411 there was another burst of transactions with 87 outputs, each output value was a multiple of 560 satoshis, also with alphabetized outputs. In total there were:

Enjoy Sochi Spam

The first major spam attack I recall experiencing was the "Enjoy / Sochi" spam in July 2014 around block 310,000. The 2014 Winter Olympics had occurred earlier that year in Sochi, Russia, so it was particularly odd to get a spammy message of this nature. These transactions tended to create around 750 outputs, each one with a value of 1 satoshi. And they all originated from 1 of the following addresses:

1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z

1SochiWwFFySPjQoi2biVftXn8NRPCSQC

Interestingly, while researching this event I found analysis of a previous but clearly linked spam attack by the same entity.

The author noted that the funding transactions to these addresses created a conspicuous "tower" chain.

The interesting thing is that despite the havoc they caused across various Bitcoin forums, the 2014 Enjoy Sochi spam storm left a small footprint on the blockchain.

Why is this the case? The vast majority of the transactions entered the network and were propagated across nodes but were not mined, presumably because they were non-standard transactions with extremely low fee rates.

A unique aspect of this attack is that we've seen echoes of it return in later years. In fact, 80% of the transactions / block space taken up by this spam were confirmed years after their initial broadcast. While it's possible that they are being performed by the same entity, it's also possible that someone else saved the original unconfirmed transactions and is mining them for some reason. I suspect the latter because the transactions have the same absurdly low fee rate of 0.4 satoshis per byte, which would not even get relayed with today's network policies. When I checked the later blocks containing these transactions:

The total usage over this 3 year span:

We can also see that the entity responsible for these transactions was still active in 2018, as they were spending funds from those addresses.

2014 Single Satoshi Spam

In September 2014 a bunch of transactions with 70 outputs each with the smallest possible value of 0.00000001. This storm consisted of:

Coinwallet.eu Spam

I identified a pattern of spam transactions that occurred between block heights 364133 and 372767 (July 6 - September 2 2015) with 99 outputs of 0.0001 BTC each. This spam storm consisted of:

Unlike most other dust storms, responsibility for this one was publicly claimed by an entity going by the name "CoinWallet.eu"

This was probably the first spam attack that affected other Bitcoin users' efforts to transact. Because it filled up the mempool, the market rate for block space increased from $0.40 to $0.60 per kilobyte, and the waiting time for confirmation of transactions with relatively low fees increased from 1 to 87 blocks. We can see from the size of the UTXO set that it grew abnormally quickly during this time.

The effect on the UTXOs with tiny values was even more pronounced:

Source: https://breaking-bitcoin.com/docs/slides/2017/HuntingMobyDick.pdf

This was actually just the first wave of 4 distinct spam storms during the summer of 2015. Antoine Calvez and Laurent analyzed these transactions and gave a presentation at Breaking Bitcoin in 2017. Across all 4 waves they counted:

RIP Bitcoin Attack

A few weeks after the CoinWallet spam ended, a new flood started. These transactions tended to have 102 outputs each with a value of 0.0001 BTC.

At the time when the attack started, an anonymous user wrote “RIP Bitcoin” in one of the Bitcoin development IRC rooms. In response, Bitcoin Core developers instituted a minimum transaction relay fee of 1,000 satoshis in the 0.11.0 release.

It turns out that some researchers were monitoring the network for suspicious activity during this time and later published this research paper. They performed cluster analysis of the spammy-looking transactions and identified 10 different clusters of UTXOs - likely 10 different wallets that were automated to generate the transactions.

As you'd expect, filling the mempool with a lot of transactions creates more contention for block space, increasing the fees required for faster confirmation.

The researchers categorized 385,256 (23.41%) out of 1,645,667 total transactions as spam between July 7th and July 17th. This attack had a negative impact on non-spam transactions, increasing average fees by 51% (from 45 to 68 Satoshis/byte) and processing delay by 7 times (from 0.33 to 2.67 hours). This showed that an adversary who is willing to spend modest amounts of bitcoin (at least $49,000 USD) can have effects on the rest of the users on the network.

"The Giv3r" Spam

In August 2015 a new anonymous Reddit account made an odd post containing a bunch of private keys:

By examining the patterns of transactions that made deposits to this addresses such as 1BhXei2ZzdqXQzFWWoDzyDU3kxHXhJ57nQ we can see that this attacker was also creating the dust during the first week of July 2015. These deposit transactions were not as spammy as the CoinWallet dust, however. While they also made outputs with 0.0001 BTC values, they tended to only have 12 dust outputs and they also paid market transaction fee rates. Analysis of "The Giv3r" deposit spam transactions shows:

In order to help clean up the UTXO set from all of this spam, F2Pool went to the trouble of creating non-standard transactions that filled an entire block, such as this one. Some of these blocks were highly CPU intensive due to the quadratic hashing nature of transaction signatures; Bitcoin developer Gregory Maxwell reached out to F2Pool and suggested using the same signature for each input in the large transactions, making them far easier for nodes to verify.

CoinWallet Giveaway Spam

The CoinWallet entity kept pushing for Bitcoin to adopt the BIP101 block size increase proposal and thus announced a new stress test for September 2015. According to the plan, 20 servers were to forward 750,000 transactions to each other in the amount of $0.03 (0.0001 BTC), which would increase the mempool backlog length to a month. But just a day before the launch, the company canceled the test and instead released several hundred keys to wallets containing a total amount of 200 BTC - about $47,500 at the time. Naturally, thousands of users rushed to import these keys and ended up generating a ton of transactions, many of which were double spends.

One last note on CoinWallet because a number of news organizations reported on it as if it was a legitimate company at the time. I had never heard of CoinWallet before this stress test and I have never heard of it since, so I did some more digging...

Conclusion: CoinWallet.eu was a sockpuppet used as a front for political purposes.

October 2015 Spam Consolidation

Another round of spam occurred on October 7th and 8th, with over 88,000 transactions raising the mempool size to over a gigabyte. This was from the consolidation (spending) of many 0.0001 BTC UTXOs that were created in late July via 51-output transactions. Nodes running on Raspberry Pi and other RAM constrained systems experienced performance issues to the point that over 10% of reachable Bitcoin nodes became unresponsive or crashed.

This particular wave of spam consisted of:

In response, Bitcoin Core developers bumped the default minimum transaction relay fee from 1,000 to 5,000 satoshis.

Bump minrelaytxfee default by laanwj · Pull Request #6793 · bitcoin/bitcoinBump minrelaytxfee default to bridge the time until a dynamic method for determining this fee is merged.This is especially aimed at the stable releases (0.10, 0.11) because full mempool limiting, ...

2016 Spam

In terms of obvious waves of spam that can be seen from dust output volume, 2016 was actually a quiet year. However, there is reason to believe that one of the spamming entities was quietly continuing their flood until early 2017. Laurent of OXT.me has pointed out that there is a clear pattern that a large swath of UTXOs created in July 2015 were being methodically spent over the next 18 months.

November 2016 - A New Record

Some odd activity occurred during the last week of November. These transaction patterns did not get picked up by my heuristics because they only had 17 outputs each and the output values are random. However, several researchers noticed the uptick at the time and we discussed it on Twitter.

Antoine noticed that this suspicious pattern of 17-output transaction abruptly stopped, restarted, and then stopped permanently. This leads me to believe that the person behind the transactions started hitting some limits that prevented them from further increasing the rate of their transaction creation and broadcasting. One possible explanation would be unconfirmed transaction chain limits that prevent new transactions from being relayed if they have many unconfirmed parent transactions.

This wave of spammy transactions consisted of:

2017 Spam

A new round of spam started in March 2017; many of these transactions had 51 outputs each with a value of 0.0001 BTC. These transactions really didn't try to hide their spamminess as all of the outputs would send the same value to the same address. This pattern continued for several months. All in all, the attack consisted of:

A new record of 100,000 unconfirmed transactions in the mempool was reached on February 23, 2017 and on May 19th it topped out at 177,000 unconfirmed transactions.

Source: https://statoshi.info/d/000000020/memory-pool?viewPanel=2&orgId=1&from=1487140490714&to=1495349011367

2018 Bestmixer.io Spam

On October 23rd, Bitcoin users began receiving 0.00000888 BTC from BestMixer.io from their vanity address "1BestMixVhna91MkP7pKRtjej3bFq6Ze46" along with a message promoting their service. Ciphertrace reported on this with the theory that they were trying to taint tons of addresses and make it more difficult to trace funds from the mixer. Ultimately this spam attack was negligible in the grand scheme of things; it's not even noticeable on the charts. Bestmixer sent 60 transactions and spent 0.5 BTC and 0.03 BTC in fees. They ended up getting raided and shut down about 6 months later. The spam consisted of:

Memo.sv Spam

In 2020 we saw spam transactions such as this one with vanity address outputs pointing to a URL on a BSV forum.

BSV spam started on July 31, 2020 and has been ongoing for 7 months with over:

There was also some copycat Monero spam that you can see at the 1WhyNotMonero777777777777a14A99D8 vanity address, but it was only used in a total of 10 transactions and was thus insignificant.

What Have We Learned?

While it's clear that many attacks simply targeted addresses that had previously received funds on the blockchain, some spam was sent to addresses that had never received funds. For example, this address was posted on the bitcoin-otc web of trust and received such an output in 2014. We can conclude that some spammers scrape web sites and forums to find bitcoin addresses.

Attempts to degrade the network's reliability at processing transactions have become more and more expensive to pull off over the years. If we take the earlier chart of fees paid by spammy transactions and denominate them in USD by the exchange rate at the time of the transaction, we can see that the cost is increasing by orders of magnitude.

Total fees paid by spammy transactions

One of the main reasons of having transactions fees is to disincentivize spammy and inefficient use of the network. Given that the block space consumed by spammy transactions has been decreasing over the past few years, this appears to be working.

Similar to the costs imposed by transaction fees, the increasing minimum required bitcoin output values have also raised the capital required to spam the blockchain by orders of magnitude.

Bitcoin is an antifragile network. That which does not kill it makes it stronger!

We have seen a variety of attempts to flood the network over the years and the worst they have been able to accomplish is to create temporary inconvenience and annoyance for other users of the network. It should be clear by now that transaction spammers are simply burning their money.