Lessons learned from 1400 Bitcoins loss

The recent news about 1400 bitcoins loss caused a lot of buzz:

  • the amount of Bitcoins worth about 16.3 million $
  • not any kind of exchange hack
  • all happened using Electrum wallet – one of the oldest and still very popular Bitcoin wallet

The story touched me a little bit. First of all kind of instant huge tragedy for the legit owner of these Bitcoins. Taking into consideration that it’s such a big loss made just by few simple mouse clicks – this is something what created some reflections in my mind about digital “wealth” ownership in general.

Since everything was described in the Internet – I am not 100% assured about the validity of the story. Even so I believe there are plenty of lessons to be learned from that story (even if it didn’t happened!) and I would like to share them here.

The story

There was existing Electrum issue thread on Github (https://github.com/spesmilo/electrum/issues/5072) from 2019 describing the Bitcoin loss due to malicious Electrum wallet installation after update request dialog (displayed in valid wallet).

On 29 August 2020 new message appeared in the thread:

User identified by 1400BitcoinStolen username claimed to lose 1400 Bitcoins using the method described in the issue thread. Information given in the thread confirm existence of total 1400 Bitcoins split on few addresses which seem to be controlled by attackers.

What happened? – technical details

Electrum wallet is the client for Electrum server. The architecture is based on 3 components: client (Electrum wallet), server (Electrum server) and blockchain (Bitcoin node). Wallet (client) interacts with server which then directly interacts with Bitcoin blockchain. It means that for example sending transaction (sending Bitcoins to another address) is not directly broadcasting blockchain transaction from client but rather request to the Electrum server which then broadcasts the transaction to blockchain. Of course due to all the cryptography based magic such request contains everything required to broadcast transaction by server (payload sent to server contains signed data with user private keys).

Due to vulnerability present in Electrum versions lower than 3.3.2 there was a very specific possibility by Electrum server to reject sending transaction to blockchain. Server could return error message to the client (Electrum wallet). There is nothing extraordinary in that yet – this is how the flow is usually built: in case of error server returns error message to the client. The question is: what will server do with such message? In that case the error message could be HTML code which client could display in error dialog. In general such behavior opens the gate for attackers.

electrum wallet bug popup
Dialog displayed in the Electrum wallet due to malicious Electrum server response (source: https://github.com/spesmilo/electrum/issues/4968)

Attacker has plenty of malicious Electrum servers waiting for client (wallet) connection – which is done automatically. If client connects to the malicious server, such server rejects the transaction request (which was made by user who simply wanted to send his Bitcoins). Server returns the error message about old Electrum wallet version and necessity of update. Client shows the dialog to the user with error message which contains the link to the newer Electrum wallet version. The point is that that link directs user to the page where he can download malicious wallet version. The modified by attackers wallet has the possibility to send the owner funds without any confirmation – simply steal all the funds. This is exactly how it finished for few victims, including 1400BitcoinStolen.

Starting with Electrum 3.3.2 the vulnerability was lowered by disabling HTML displaying in the dialog. In further Electrum versions client could not display every error message sent by server.

Read more here: https://github.com/spesmilo/electrum/issues/4968

Who failed?

Electrum architecture based on client -> server -> Bitcoin node is not very extraordinary. Server does a lot of work which cannot (or shouldn’t) be done by node e.g. is indexing the operations made by user. Every user can connect to his own Electrum server when using Electrum wallet. Of course in most cases users don’t run their own servers this is why they connect to one of pool’s servers. In that case user connected to malicious server.

In general the possibility of displaying HTML in error popup gave the attackers possibility to mislead the user – to show him the message in the way that he didn’t notice it’s the fraud. In that case in my opinion it could be considered as a vulnerability which in fact lead to funds lost in case of few users including huge loss of 1400BitcoinStolen.

However it’s worth to notice that it’s not Electrum fault that the user used the vulnerable wallet version (this vulnerability was fixed in further versions released). It’s also not Electrum wallet fault that the user downloaded not legit wallet version following the popup link.

Lessons to be learned


Lesson 1: open source requires responsibility

Responsibility of the software users not software creators.

What I mean by that is that most of the open source projects are as name suggest open. You can download the code from Github, compile it and run by yourself. Usually code creators provide possibility to download ready to run binary. Open source based products can be free or paid. Of course paying for something opens the space for customer rights and demanding the quality of the product. But is the case of free open source projects?

Electrum wallet is free product. You can download and use whether you like it or not. Actually this is exactly what attackers did and why they succeed with their hacking scenario. Because Electrum wallet is opened and free to use – they cloned the repository, changed code, used the vulnerability and user mistake.

The general question is: should you demand anything from such kind of product? I would say not really. Running that software you agree on the terms of using it – simply no warranty.

Open source idea and movement is one of the greatest things in the IT industry. Linux is open source, Bitcoin is open source. However not every open project build good quality and safe to use product. In case of Electrum it showed within years of existence that it is good product, however it shouldn’t be taken for granted by default in case of every open source project.

Don’t trust everything you run in the Internet. Verify as much as you can. Verify the history of the project, verify the community, verify software checksum, read about it. If this is bad product – you will probably read about it in the net. You cannot predict everything, bugs can happen even in good software – however it’s your responsibility as the user to lower the probability of any kind of failures as much as possible.

Lesson 2: crypto requires fresh knowledge

1400BitcoinStolen lost his coins due to old vulnerability in the software. The situation could not happen if he downloaded the newest version of Electrum before sending his coins.

A lot is happening within developing space and things change all the time. This industry forces to stay up to date since changes are constant, whether it’s kind of protocol upgrade, new features or vulnerabilities fixes in software (strange bugs like in this case). Sometimes the project after some time appears to be scam. The point is that it’s important to stay fresh within industry news in order to lower the probability of making bad or loosing assets like in the case of our story hero.

Lesson 3: use hardware wallet?

I’m not the huge fan of hardware wallets since they are another layer of complexity. However the truth is that in most cases they provide kind of higher security than software wallets.

If 1400BitcoinStolen would use hardware wallet for storing his Bitcoins – he would not probably be hacked in the way it happened. Hardware wallets, e.g. Ledger are designed to validate the software installed on the device (to be sure it’s valid). They also require to confirm the critical actions (like sending transaction) directly on the device. This requirement for physical action – like the buttons click in the device provide greater security and helps to avoid situations like missclick in the window dialog displayed on the screen.

If you’re not fan of hardware wallets but operate with decent amounts of cryptocurrencies – be sure that your digital hygiene is enough safe. Use up to date software, consider booting live Linux distributions when sending crypto.

Lesson 4: have in mind – there is no 100% security

It’s worth to remember that there is no 100% security. The point is to maximize the security as much as possible.

You can visit MyEtherWallet and assume you are using legit tool, but can you be sure that site code is not hacked even if yesterday it worked correctly? You can use legit software but can you be sure that there is no bug? I repeat myself but in the evolving space with valuable digital assets involved such situations can happen. Be suspicious and maximize your security as much as possible.


I hope that the story will end well for 1400BitcoinStolen. Blockchain is one big transactions registry so it’s possible to spy stolen Bitcoins. From the other side there are also possibilities of coins mixing which complicate that process.

I learned to be more suspicious and and take things serious when operating with cryptocurrencies. These are 4 lessons I believe worth to remember:

  1. Open source requires users responsibility. Verify the software you use especially if it’s free product.

  2. Crypto space requires up to date knowledge. Stay tuned with news, spend some time to refresh the knowledge when you come back to crypto after some time.

  3. Consider using hardware wallet. If not – maximize your security by using verified software on verified software and hardware (malware free OS and trusted hardware).

  4. Remember – 100% security doesn’t exist. Be suspicious – it’s sometimes better to waste some time on research, to not proceed with some strange application behavior than to loose your digital wealth.