Are Your Bitcoins Safe From Hackers?

After barter, gold-backed currencies and fiat currencies, the recent emergence of cryptocurrencies have disrupted the global economy. Instead of being backed by assets or governments, cryptocurrencies are backed by computers of volunteers, which fixes some problems but also introduces new ones.

Today, we will focus on the security risks associated with cryptocurrencies. Note that this is not a case against using them, as I am not familiar enough with modern banking systems to compare the security of both.

An overview of how it works

Existing cryptocurrencies are managed through blockchains, which will be the main focus of this blog post, so most of the information presented below applies regardless of whether a blockchain is used for cryptocurrency or for other means.

A blockchain is a public ledger shared on a peer-to-peer network. Instead of having its information stored on pages, they are stored on blocks, which are simply chunks of computer data with a specific structure. With the exception of the first block, each block contains the hash value of its previous block, chaining them together, hence the name.

Accounts in blockchains are managed by public-key cryptography. Each account owner keeps a private key that allows them to send assets such as cryptocurrency money stored on them, while publishing a public key that allows them to receive said assets.

To ensure that a blockchain is not falsified, a block must conform to mathematical requirements that makes it hard to compute, classically by including a nonce to force the block's hash to have a specific number of leading zeroes.

In addition, a set of predetermined consensus rules ensures that only a single valid blockchain is retained. Consensus rules very between blockchains, but a very common one, if not universal, is to ensure that the blockchain with the most blocks has priority, again to prevent falsification.

People contributing computer resources to the blockchain are called miners, because they may be allowed to create assets in exchange for their work. Classically, only the creation of valid blocks was rewarded, but some blockchains also reward sharing network resources.

Note that while the information in a blockchain is public, the type of information allowed in it may grant additional privacy features to it, but we will not be focusing on those.

Main use cases

This is how people would normally use blockchains in the general case.

Note that actor information is not included, as their definition are blurred between blockchains.

Get Latest Blockchain

Prerequisites: None

  1. Download the first block of the blockchain from a trusted source
  2. Request the rest of the blockchain from a peer-to-peer network
  3. Validate returned blockchains from the trusted first block
  4. Keep only the best blockchain according to the consensus rules

Create Account

Prerequisites: None

  1. Generate a key pair
  2. Store the private key securely
  3. Send the public key through the blockchain's peer-to-peer network
  4. Wait until the public key is published in the blockchain

Send Blockchain Assets

Prerequisites: Sender and receiver created accounts

  1. Determine which assets assigned to you in the blockchain to transfer to the intended recipient, along with his public key
  2. Sign the transaction using your private key
  3. Send the signed transaction through the blockchain's peer-to-peer network
  4. Wait until the transaction is published in the blockchain

Add New Block

Prerequisites: A recent blockchain has been acquired

  1. Compile pending new accounts and transactions from a peer-to-peer network
  2. Find a block meeting the mathematical requirements and which contains the hash of the previous block, the compiled data and which account created assets should be assigned to if applicable
  3. Publish the extended blockchain to other actors through the blockchain's peer-to-peer network


After analyzing each step of the normal use cases, I came up with the following list of vulnerabilities.

Controlling the discovery of peers

Peer-to-peer networks are so common nowadays that it's easy to forget that at some point, peers need to find each other, and that random encounters rarely yields results. To work around this, centralized lists of peers are maintained where they can announce their availability.

However, this also introduces centralized points of failure in the decentralized nature of the blockchain. If a malicious party controls one of these centralized lists either legitimately or not, for example by modifying the response of a DNS query, they can potentially disrupt the discovery process to fragment communities, and in some cases block them completely, in order to sabotage the blockchain.

Blocking communications

Communications between specific areas of the world may become unavailable, either due to technical issues, failure of critical equipment or geopolitical conflicts. During that period, different versions of the blockchain can live independently between those areas. Once communications are restored however, only one blockchain will survive due to the consensus rules, reverting all transactions of the rejected blockchains.

Also, the communications protocol used may contain various security vulnerabilities that would allow malicious people to take control of some peers in the network and cause substantial damage.

Bad blockchain validation

Validating a blockchain is an arduous problem best left for a program to execute. The problem comes when a widely-distributed blockchain validation program contains a bug.

At best, it will accept or refuse the wrong data as the current blockchains, causing false blockchains to live alongside the correct one, potentially causing major disruption to the economy until the matter is resolved.

At worse, the program will contain an arbitrary code execution bug, potentially giving full control of a computer to an attacker by sharing a blockchain with injected code.

Losing trust

What if a significant amount of people suddenly want to update the consensus rules because of a bug or design flaw? For example, what if the normal process of creation, transfer or destruction of assets on the blockchain is either bypassed or slowed down to an extent that interferes with its normal usage?

If the desire for change is unanimous there is no issue, but this most likely won't be the case, which won't only impact the value of the assets stored on the blockchain. Those choosing to exit may reduce the security of the blockchain due to the resulting lower computational resources. Those choosing to adapt may create a parallel blockchain altogether based on the original blockchain, fragmenting communities and security. Those choosing to force a solution may attempt to disrupt the normal processes of the blockchain altogether, potentially causing even more damage.

Storing the private key at a vulnerable location

Private keys are extremely hard to remember for most people, so they need to store them somewhere safe.

First, there's always the issue of losing access to the storage, or having the storage destroyed, losing access to the linked assets. To counter that, a responsible person will need to store his private key at multiple locations. However, doing so increases the risk of having the private key exposed to malicious individuals and siphon all linked assets, losing access to it as well. To counter that, the private key must be protected by additional means, for example by a password that can be remembered.

Then, there's the usability factor, as securing private keys also makes them less convenient to use. Unfortunately, there will always be people that will refuse to use secure storage because it make things more painful for themselves, or will not realize the risk of sharing its private key to a third-party and be socially engineered to do so.

Banks handling cryptocurrencies are especially sensitive to this problem. If they lose their private keys, they lose all of the money they haven't invested yet, including customers' deposits.

Discovering the private key from the public key

The whole reason public-key cryptography works is because it is considered infeasible to reverse-engineer the private key. However, this is based on many assumptions.

As more and more public keys are created and exposed, the possibility of finding a valid private key by luck, through a birthday attack for example, also grows. This may become a problem if the number of possible public keys turns out to be too small.

The cipher used may also contain other security vulnerabilities due to subtle bugs, and attacks may become available as they are discovered or as additional computational power becomes available to execute them. For example, public-key cryptography is based on the unsolved P vs. NP mathematical problem. Depending on its resolution, it may become feasible to crack all public-key ciphers.

In addition, the emergence of new technology, such as quantum computers, may also create new types of attacks that some public-key ciphers were not designed against.

Substitution of public keys

How would you verify if a specific public key really is controlled by a specific entity? For example, if a merchant exposes its public key on its website, but that website has been hacked to show a different public key, a consumer may transfer its money to the attacker's account, in which case it will be too late.

There is the possibility for trusted independent entities to certify the identity of owners of public keys in blockchains, similar to how certificate authorities generate Extended Validation (EV) certificates for HTTPS websites. However, as far as I know, such trusted entities do not currently exist.

Reversing a block

So when does a transaction becomes final anyway? The answer is: never.

The problem is that there is absolutely no guarantee that once a transaction is added to the blockchain, that there's won't be another blockchain without that transaction that will take priority due to the consensus rules.

In practice, people wait until a few additional blocks are appended to the blockchain after the block containing the transaction to minimize that risk to an acceptable level before confirming the transaction. However, the risk is still present and malicious individuals may attempt to exploit this flaw, so transactions should be managed to ensure as much as possible that traded goods or services can be reacquired if a block is reverted.

Controlling a majority of resources to create blocks

Ultimately, is it miners that decide what is added to the blockchain and what doesn't. A good blockchain will attempt to have monetary incentives for miners in a way that encourages them to cooperate. Isolated sabotage attempts by computing dummy blocks will only slow down the process at worse.

A problem occurs when the majority of the processing power invested into a blockchain is for sabotage, for example by privacy-averse governments. In this case, rogue miners are able to create blocks faster than normal miners, potentially allowing them to ignore blocks created by normal miners and taking full control of the blockchain through consensus rules and potentially blocking all transactions in which they disagree with.

Replacing segments of blocks

Blocks in a blockchain are linked together through their hashes, and protected by the mathematical requirements of a block. However, in theory, it is possible to compute a block with the same hash but containing completely different information. A good hash algorithm will make such attacks infeasible.

However, similar to public-key cryptography, hash algorithms may be vulnerable to birthday attacks and other subtle security vulnerabilities that make finding collisions easier and feasible. If a collision is found somewhere, then it may become possible to replace a block segment within the blockchain by a longer block segment, potentially giving it priority through consensus and effectively re-writing its history.


Here is the list of blockchains I analyzed prior to writing this post: