Abstract: In this piece we cover four rounds of spam attacks on Bitcoin in the summer of 2015, apparently initiated by a London based company called CoinWallet.EU. The spam had a significant detrimental effect on the user experience of those making Bitcoin payments at the time, especially in round three of the attack on 7th July 2015 to 11th July 2015. The attack sparked debate about miners filtering spam transactions and the blocksize limit. In our view, the attack played a critical role in formulating the views of many with regards to how to deal with spam and there are interesting parallels to today’s debate over the OP_Return relay limit.
Overview
In the Bitcoin Core software repository, it has recently been proposed that the policy limit on the size of OP_Return outputs should be removed. We already provided our opinion on this issue. This move proved somewhat controversial and has reignited the debate about what constitutes spam on the Bitcoin blockchain and what to do about the spam. In this article, we look back one decade to the summer of 2015, when the Bitcoin network was under attack by spammers. We aim to draw parallels between what happened back then and today and explore what lessons were learnt back then.
The spam attacks of the summer of 2015 were an early salvo in The Blocksize War. The attackers were larger blockers, hoping for an increase in the blocksize limit. A key argument from the larger blockers at the time, was that the 1MB limit was far too small, such that blocks could easily be filled up by spam transactions, for a relatively small amount of money. This scenario, full blocks, was considered an extremely bad outcome by the large blockers, it represented the spammers winning. Full blocks, in the view of the larger blockers, would make using Bitcoin for payments unreliable. Large blockers wanted to increase the blocksize limit to make it more expensive for spammers to fill up all the space in the blocks. The logic was, that at a fixed fee rate, filling up an 8MB block with spam would cost a lot more than filling up a 1MB block. The small blocker retort to this argument was that the larger blockers had it backwards, if there is spam, letting it all go onchain quickly and cheaply wasn’t stopping the spammer, but letting the spammer win. Besides, if the blocksize limit was increased, fees would decline, making the spam cheaper. However, a key metric to the large blockers was how much money it would cost in fees to fill a block. This number was considered far too low for Bitcoin to be secure and raising the blocksize limit would help increase this value, making Bitcoin more resilient, in their view.
The Spam Attacks
Round 1
On 20th June 2015, a little known supposedly London based Bitcoin wallet provider and exchange called CoinWallet.eu announced on BitcoinTalk and Reddit, that it was conducting a “Bitcoin Stress Test”. We have been unable to establish much information about the entity, for instance who the management team were or who the shareholders were. We were unable to find any meaningful WHOIS records or company registration documents, while the London address (78 York Street) appeared to be a virtual address.
78 York Street in London (Google Street view)
However, the attackers, CoinWallet.EU made clear their motives, to demonstrate the need for an increase in the Blocksize limit.
Bitcoin is at a breaking point, yet the core developers are too wound up in petty arguments to create the required modifications for long term sustainability. If nothing is done, Bitcoin will never be anything more than a costly science project. By stress testing the system, we hope to make a clear case for the increased block size by demonstrating the simplicity of a large scale spam attack on the network.
The attackers explained that they would “generate 1MB worth of transaction data every 5 minutes”. The attack was set to take place on 22 June 2015. The plan was to “backlog of transactions will be approximately 241 blocks, or 1.67 days”. This would be a transaction backlog of over 241MB.
Luke-Jr responded to the attackers on Reddit at the time, stating:
Bitcoin has miners and the block size limit specifically to combat these kinds of attacks
Source: https://www.reddit.com/r/Bitcoin/comments/3agk61/comment/cscgipz/
On 24 June 2015, the attackers announced that the attack was not as successful as they had anticipated, because their servers began to crash after around 2 hours, when mempool sizes were around 12MB. The attackers said that “Bitcoind is not well suited to crafting transactions of this size”. The attackers also disclosed that they spent around 2 BTC or EUR 434 in fees on this failed attack.
Round 2
On the same day, 24 June 2015, CoinWallet.EU announced that a second spam attack would take place on 29 June 2015. Again, the objective was to build the mempool up to 241MB.
As the above image indicates, the attack was working more effectively this time, with some users apparently agreeing with the large blocker narrative that it was making Bitcoin unusable.
Could somebody explain me what the f…. is going on? I bought 0,05BTC via our local web exchange and they sent me it to my wallet with tx fee 0,0001. This tx has 226bytes. It was rejected by blockchain.info node after 7 hours of waiting for confirmation. Exchange has sent it to me again with tx fee 0,0002. There is status estimated confirmation time VERY SOON (High priority). But it is waiting for 6 hours now! What the hell have you done with BTC?! Is it normal? BTC will not be usable for everyday txs this way. Tx fee 0,0002 is not enough for 226bytes-tx?
Source: https://bitcointalk.org/index.php?topic=1098263.msg11847265#msg11847265
Luke-Jr’s mining pool, Eligius, appeared to successfully filter out the spam at the time. The Eligius blocks were much smaller than those produced by the other pools during the attack, which were typically either 1MB or 750KB, whatever limit was set.
Luke’s earlier prediction was correct, the blocksize limit and the miners helped mitigate the impact of the attack. Except it wasn’t all miners, it was only his own mining pool. While the impact of the blocksize limit was much stronger in stopping the spam getting onchain, in our view. Luke’s spam filtering policy at the time was controversial. With some arguing that Luke’s “blacklisting” damaged Bitcoin’s fungibility and that it helped prolong the attack, by keeping the mempool larger for longer. For example, the operator of the Kano mining pool reasoned about the spam, on the BitcoinTalk forum that:
The simple fact is that they were valid transactions with fees
Another member of the forum, wizkid057, a colleague of Luke at Eligius defend the filtering, just like colleagues of Luke at Ocean pool support the pro-filtering position today:
The only things prolonging the attack are the attackers and other pools/miners *not* filtering the scammer’s spam. The other pools/miners would rather fill their blocks with the attacker’s transactions for an extra 0.1 BTC in fees vs protect bitcoin as a whole… or it’s laziness. Either way, any ill effects of this attack could easily have been countered 100% with the participation of just a few of the larger pools.
Source: https://bitcointalk.org/index.php?topic=1098263.msg11760038#msg11760038
Our understanding is that wizkid057 works at Ocean pool with Luke today. Another user of the BitcoinTalk forum, “spartacusrex”, agreed with Kano, saying:
A valid TXN is a VALID txn. Full stop. End of story. NO POLITICS. If someone starts to show that it is possible to ‘edit’ which transactions go through the system, then I think it sets a very bad precedent.
Round 3
On 7th July 2015 there was a third round of attacks. However, as far as we know, there was no official announcement by CoinWallet.EU this time, although due to their previous actions, they were the main suspect, along perhaps with those who may have been affiliated to them. Over the next couple of days, people reported their mempools had between 27,000 to 80,000 transactions. This was by far the most intense attack so far and was multifaceted, causing a degree of chaos on the network.
Motherboard reported that more than $8,000 (30 Bitcoin) was spent in fees on this attack, far more than EUR 434 the previous time. This time the attackers had a wider variety of tactics to generate as much spam as possible. For example many dust transactions were sent to public wallets, like the Wikileaks wallet and the wallet of startup Reddit competitor Voat.
The spammer also sent dust amounts of Bitcoin to addresses where the private keys were publicly known, for example to the brainwallet generated by the word “cat” or “dog”. This helped create even more spam, since other users could then create more spam transactions trying to redeem the funds, while the attacker’s servers did not need to create these transactions themselves. For example, the Bitcoin address generated by the word “cat”, using uncompressed keys, had over 41,000 transactions associated with it in July 2015. The address was sent thousands of outputs, each worth 0.00001 BTC. While the Bitcoin address generated by the word “password”, using uncompressed keys, had 45,000 Bitcoin transactions associated with it in July 2015. The address generated by the word “dog” had over 43,000 transactions. The spammers therefore clearly demonstrated an amount of ingenuity and expertise to conduct this attack.
During the height of the attack, Bitcoin developer and large block advocate Mike Hearn argued that increasing the blocksize limit was the best defence against such an attack.
The best defence against this is to make it as expensive as possible, by increasing the block size limit. Which of course I am working on as well.
Source: https://www.reddit.com/r/Bitcoin/comments/3ck5z9/comment/cswda6x/
The mining pool F2Pool helped clean up the mess, by creating a 1MB transaction consolidating these spam outputs, helping reduce UTXO bloat. With over 5,000 inputs, the 1MB transaction was computationally challenging to verify, taking nodes up to 20 seconds to check it, due to the quadratic scaling of sighash operations weakness in Bitcoin at the time. A few days later, Bitcoin developer Gregory Maxwell is said to have helped F2Pool use the same signature for each input, making the transaction easier to verify. For example this other 1MB transaction, with over 7,000 inputs. More precisely, the first input had a unique signature which signs the hash of the transaction, while all the other inputs had the same signature and did not sign a hash of the transaction. With Gregory’s more efficient consolidation, each input is signed using SIGHASH_SINGLE, rather than SIGHASH_ALL. SIGHASH_ALL is where the signature signs all the inputs and outputs, which is the default behaviour. This difference is now nicely indicated on the mempool.space website, a nice new feature added in May 2025, with green keys for SIGHASH_ALL and a blue key for SIGHASH_SINGLE.
Round 4
There was then a fourth and final round of the CoinWallet stress tests, this time in September 2015.
There are many opposing viewpoints about tomorrow’s announced stress test. Some are calling it an attack on the network, however we see it as no different than someone purchasing all of the tickets on a train to have the whole train to themselves. We have spoken to multiple lawyers and the general consensus is that such a test does not violate any laws in the EU or elsewhere.
Someone claiming to be “James Wilson”, the CoinWallet.EU COO or CCO emailed various media outlets to talk about the attack. Wilson said:
The goal is to get the community to fix Bitcoin. It is broken right now. A small wallet startup should not be able to bring the network to its knees.
In this fourth attack, CoinWallet.EU had a different approach. The company announced it would be giving away 200 BTC, by literally posting the private keys onto the BitcoinTalk forum. The original post contained 5 private keys, each with a 0.53918 BTC balance. In the thread, over the next few days, the Coinwallet account published thousands of private keys with balances in them. This resulted in a flood of over 90,000 transactions being generated, many of them conflicting transactions which could therefore be discarded, using the First Seen Safe (FSS) principle. This made the impact of round 4 less severe than round 3.
With this latest experiment, the company announced that their “stress testing days are officially over” and many Bitcoiners declared victory.
As for who was behind CoinWallet.EU, this remains a mystery. Theories include the following:
- The former Quadriga CEO Gerald Cotton could be behind CoinWallet, because when making a money order to CoinWallet, clients were told to set the payee as 1009926 B.C. LTD, the same as Quadriga. However, this could just be CoinWallet using Quadriga as the payment processor or Quadriga and CoinWallet using a common processor.
157 Adelaide Road, Toronto (Google Street view)
- The apparent CoinWallet COO, James Wilson, could be former Craig Wright colleague Jamie Wilson, implying Wright may be involved in the spam attack. Or perhaps it is another faketoshi, Phil James Wilson (AKA Scronty), who said his family often call him James Wilson. (James Wilson is quite a common name)
To us, the above theories are too weak and there is not enough evidence to conclude who was behind CoinWallet at this point.
Academic Analysis
An academic paper was published, which covered the 2015 spam attacks. The published data shows two main peaks in the size of the memory pool, to around 175,000 transactions, lining up with round three and round four of the spam attacks.
The paper concludes with the following:
We have presented an empirical study of a spam based “stress test” DoS attack against Bitcoin. Using our clustering based approach we find that 385,256 (23.41%) out of 1,645,667 total Bitcoin transactions were spam during a 10 day period at the peak of the spam campaign. We also show that 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 shows that an adversary who is willing to expand modest amounts of bitcoin (at least $49,000 USD), to pay higher fees, can DoS Bitcoin.
Conclusion
In our view the 2015 spam attacks had considerable implications for Bitcoin. Both technical implications for Bitcoin relay policies and it was also somewhat an influential set of events, helping people formulate opinions on spam on Bitcoin. Possibly as a result of the attacks, the following changes occurred to the network:
- Miners increased the blocksize limit policy from 250KB or 750KB to 1MB. 1MB was the consensus limit and miners altered their policy from the defaults to 1MB. This is an example of miners changing the policy constraints to match the consensus rules. The idea here is that this would increase the capacity in blocks and make it harder for a spam attacker to fill up the blocks and damage the user experience.
- In October 2015 the minimum relay fee in Bitcoin Core was increased by 5 times to 5,000 satoshis. This decision was likely made to help fight against the spam.
- The spam attacks also appeared to accelerate the introduction of mempool limits into Bitcoin Core and the 300MB default mempool size limit was adopted shortly afterwards. Some of the discussion occurred in October 2015, with pull requests happening during or shortly after the attacks, for example 6557 and 6722.
The spam attacks also appeared to increase the tension and polarisation in the blocksize limit debate. The large blockers, some of which were involved in conducting the attack, used the degraded user experience during the attack as evidence that the blocksize limit should be increased. Some large blockers seemed pleased that this attack had brought the blocksize limit to the top of the agenda and acted as a catalyst for further debate. If one is being sceptical, one could even argue this was a coordinated and deliberate approach to try and get more grassroots user support for a blocksize limit increase. However, the small blockers remained resolute and stood their ground.
Of course the small blockers won the war. Blocks became full and this is now the normal state of affairs. It is now a settled issue, that its not a good idea to increase the blocksize limit to allow more spam onchain. However, the debate over what constitutes spam and how to deal with it from a relay and mining policy perspective wages on. For those not around in 2015, one key takeaway from this piece may be that spam attacks are nothing new. If anything, in our view, the malicious intent from the attackers in 2015 is probably more clear, compared to the more murky and perhaps more legitimate intent of those producing jpeg related transactions from 2023 onwards. Another interesting comparison is the amount of money spent in fees, in 2015 it was perhaps around $10,000 that caused the damage. While since 2023, hundreds of millions of dollars have been spent on fees in the “spam” transactions.