Home

Awesome

alt text

Bitcoin Threat Model

A security review of the Bitcoin cryptocurrency


Motivation

The Bitcoin threat model is intended to help developers, investors and users better understand the security of Bitcoin. Threats are assumed to be any activity designed to prevent Bitcoin from accomplishing its mission to become cash (including a unit of account).

Conclusion

Currently there are no threats that have been identified that could prevent or significantly slow adoption of Bitcoin as cash. However, new threats could be discovered or existing threats may prove to be more impactful. Given the impact Bitcoin is likely to have, and the frequency and intensity of past attacks, this remains a real possibility.


<!-- START doctoc generated TOC please keep comment here to allow auto update --> <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> <!-- END doctoc generated TOC please keep comment here to allow auto update -->

Introduction

Under each threat is a description of the threat, the safety features designed to protect against the threat, and any past examples of attacks executing the threat.

Bitcoin can be attacked directly by making the software behave in a way that is ineffective as cash or by attacking the humans that are needed to support the software.

Threats are categorized as one of the following:


Software Threats

Software threats are threats that take advantage of security flaws within the software to prevent Bitcoin from becoming cash.

Creating a transaction

Owners of Bitcoin can send their Bitcoin to another user by creating a digitally signed transaction and broadcasting it to the Bitcoin network. The piece of software that creates transactions is called a "wallet." For a transaction to be accepted by the network it must be digitally signed using the owners private key. Keeping the private keys secret is also handled by the Bitcoin wallet software.

An attacker could steal a users private keys to steal their bitcoin.

If an attacker can gain access to a users private key he can send the associated bitcoin to himself.

Safety Features

Past Attacks

No Impact on Adoption

An attacker could use a quantum computer to guess everyone's private keys.

If an attacker could gain access to everyone's private keys he could steal every bitcoin.

Safety Features

Past Attacks

No Impact on Adoption

Broadcasting a transaction to the network

After a transaction is created it is relayed over the Bitcoin network.

An attacker could broadcast a fake transaction to the network in order to steal bitcoins.

If an attacker could convince the network that a transaction was legitimate he could transfer bitcoins from a victims balance to his own account.

Safety Features

Past Attacks

No Impact on Adoption

An attacker could broadcast a large number of transactions that pay himself in order to clog the network.

Because anyone can broadcast a transaction on the Bitcoin network it is possible for an attacker to broadcast a large number of transactions that transfer bitcoins to themselves. The Bitcoin network has no way to distinguish between legitimate transactions and transactions created with the intention of clogging the network. If the network is unable to process legitimate transactions Bitcoin would not be suitable as cash.

Safety Features

Past Attacks

No Impact no Adoption

An attacker could identify the participants in transactions through network traffic analysis

Bitcoin transactions are broadcast across the Internet by the sender. If an attacker can view network traffic and discover the source and destination of transactions this would make Bitcoin less suitable for cash.

Safety Features

Past Attacks

No Impact on Adoption

An attacker could identify the participants in a transaction through public transaction data.

Bitcoin transactions are published on the public ledger and they contain the source, destination, approximate time and amount of each transaction. If it is possible for an attacker to discover the people involved in a transaction this would make Bitcoin less attractive as cash.

Safety Features

Past Attacks

Medium Risk

Confirming Bitcoin transactions

Bitcoin transactions are confirmed through a process called mining. To prevent double spending of transactions they are grouped together and a difficult math problem is solved using this set of transactions, and the previous set of transactions, as inputs. Sets of transactions are called "blocks." The math problem is so difficult that a significant amount of money, must be spent on electricity in order to solve the problem. The person that solves the math problem is rewarded with bitcoin, in the form of transaction fees included by the senders of transactions, and a "block reward" where additional bitcoins are created. Solving this math problem is called "finding a block." Everyone running mining software is competing to be the first to find the next block.

An attacker could run mining software in order to prevent transactions from being confirmed.

Because anyone is able to download and run the software that confirms transactions on the Bitcoin network it is possible for an attacker to mine blocks without including transactions.

Safety Features

Past Attacks

No Impact on Adoption

An attacker could run mining software in order to double spend bitcoins.

Because anyone is able to download and run the software that confirms transactions on the Bitcoin network it is possible for a bad actor to mine blocks without including transactions.

If the attacker sends bitcoin he could delay that transaction until a new transaction, using the same funds, is confirmed by the network. This would make the initial transaction invalid after it was relayed across the network.

Safety Features

No Impact on Adoption This attack is not cost effective.

An attacker could exploit a flaw in the proof of work algorithm to fake the performance of work.

If an attacker is able to find a flaw in the proof of work algorithm he could obtain the benefits of transaction fees and block rewards without doing the work required to secure the Bitcoin network.

Safety Features

Past attacks

No Impact on Adoption

An attacker could steal all of the hardware used to confirm Bitcoin transactions.

If an attacker could gain control of all of the hardware used to confirm Bitcoin transactions he could prevent some or all Bitcoin transactions.

Safety Features

An attacker could claim to be Satoshi and remove a safety feature from the next version of Bitcoin.

Satoshi Nakamoto is the name of the author of the original Bitcoin white paper and software. Because he is so well respected in the Bitcoin community he, or someone pretending to be him, could attempt to remove a security feature in the next version of Bitcoin.

Safety Features

Past Attacks

An attacker could remove a safety feature from the next version of Bitcoin to enable a new capability.

In all software projects there is a tension between adding new features or capabilities and maintaining safety features. This is often exacerbated by the fact that safety features often prevent software from being used certain desirable ways. As an example cars have speed limiters to prevent a car from driving as fast as the engine will allow but it does prevent users from racing at top speed.

Even in the most effective software projects the security vs features trade off decisions become heated and political. If an attacker is able to convince the community that a new feature is more important than an existing safety feature, the safety feature would be removed.

Safety Features

Past Attacks

No Impact to Adoption

An attacker could create a copy of Bitcoin (aka fork) that is missing a safety feature and trick people into using it.

Because Bitcoin is an open source project anyone can copy the code and build their own version of Bitcoin. If they can convince someone that their version of Bitcoin is the real Bitcoin they will have successfully removed that safety for those users.

Safety Features

Past Attacks

No Impact to Adoption

An attacker could create a variety of implementations of Bitcoin in order to add a security flaw.

If an attacker is able to create a new implementation of the Bitcoin software that is not thoroughly reviewed by Bitcoin security experts he could introduce a subtle security flaw that is not discovered before it is deployed.

Currently the vast majority of expertise is focused on a single repository and this makes it very difficult for a flaw to go undiscovered.

If an attacker could create one or more Bitcoin implementations of Bitcoin it would at minimum spread out the efforts of security experts and at most prevent some implementations from being reviewed before deployment.

Safety Features

Past Attacks

An attacker could create an insecure second layer network on top of Bitcoin.

If an attacker is able to create an insecure second layer network on top of Bitcoin he could steal all bitcoin moved into the second layer network.

Historically large thefts of bitcoin,even when unrelated to security flawsin the bitcoin network itself,have resulted in signifiant decreases to the bitcoin price.

This would allow an attacker to profitin at least two ways.First, he would gain the bitcoin storedin the insecure layer two network, and second, he could "short" bitcoinand thereby profit from the decreased market value of bitcoin.

Safety Features An insecure layer two network must contain a security flaw. This allows honest participants to make it clear that they intend to take advantage of the design to drain the funds.

By being public about their intention, and their progress towards obtaining the funds, the honest actors will likely aquire more support, for example hash power,than the attackers.

This will have a few helpful effects. First, the attackers will lose significant motivation to develop the insecure layer two solution because it is unlikely that they will be able to drain the funds before the honest actors.

Second, knowledge of the ongoing project to drain the funds from the layer two network would discourage users from moving their funds into the insecure layer two network.

Third, if the attackers are aware of this they will be further demotivated to implement an insecure layer two solution because the amount of funds that will be available to steal will not be significant.

Past Attacks

Observing confirmed transactions

In order for a transaction to be completed the receiver must be confident the transaction has been irreversibly confirmed by the Bitcoin network. this is performed by Bitcoin "node" software. This software maintains a copy of the longest set of transactions presented to it that are valid. The node software considers a transaction valid if it is structured correctly, digitally signed by the bitcoin owner, and does not attempt to transfer more bitcoin than is available to the sender.

An attacker could create a less secure digital asset and trick people into buying it.

If an attacker can trick investors into using his digital asset as cash it could prevent Bitcoin from becoming cash (unit of account).

Safety Features

Past Attacks

No Impact on Adoption

An attacker could create a more secure digital asset so that investors will abandon Bitcoin.

If an attacker could create a more secure digital asset investors would abandon Bitcoin and adopt this new asset as cash.

Safety Features

Past Attacks

No Impact on Adoption

An attacker could mine invalid Bitcoin blocks to remove a safety feature from Bitcoin

If an attacker could make the network accept blocks that don't include a safety feature he would have effectively removed that safety feature.

Safety Feature

Past Attacks

No Impact on Adoption

An attacker could deceive a Bitcoin node into thinking a transaction did or did not get confirmed.

Because Bitcoin nodes accept information from any other computer running the Bitcoin node software it is possible to provide a node or a group of nodes false information about the current state of a transaction.

Safety Features

An attacker could deceive a bitcoin wallet into thinking a transaction did or did not get confirmed by the Bitcoin network.

In some cases, such as operating on a mobile phone, the Bitcoin client software doesn't perform the full validation of the Bitcoin transaction history. To the degree that the client doesn't perform complete validation safety features are discarded.

An attacker could introduce security flaws into Bitcoin mining hardware in order to break the security of Bitcoin.

If an attacker included a "back door" in mining hardware before it was shipped to the buyer he could gain control of the majority of the Bitcoin computing power.

Safety Features

Past Attacks

No Impact to Adoption

Human Threats

Bitcoin can be attacked by attacking the humans that support the Bitcoin software as network operators, investors, merchants, developers or hardware manufacturers.

Network Operators

People that run the software needed to support Bitcoin can be attacked.

An attacker could threaten to harm an individual or group mining bitcoin.

Bitcoin mining is a critical part of the Bitcoin network. Without functioning mining software no new Bitcoin transactions could be trusted.

Safety Features

No Impact to Adoption

An attacker could threaten to harm node individual or group running a Bitcoin node

Bitcoin nodes are critical to the Bitcoin network. Without a network of functioning nodes new transactions could not be relayed.

Safety Features

No Impact to Adoption

Investors

Without Investors Bitcoin would have no market value and be unsuitable as cash.

An attacker could extort the private keys from an investor.

An attacker could threaten to harm a Bitcoin investor unless he handed over the private keys to his bitcoin holdings.

Safety Features

No Impact to Adoption

An attacker could deceive investors regarding the utility of Bitcoin.

If investors were tricked into believing Bitcoin is less useful as money than another asset they would sell. If this could be achieved at sufficient scale Bitcoin would not become cash.

Safety Features

Past Attacks

No Impact to Adoption

An attacker could threaten to harm Bitcoin investors if they don't sell or hand over their bitcoin.

This is a duplicate of the threat: An attacker could extort the private keys from an investor. Using the threat of violence to force someone to hand over their private keys is essentially the same attack. The only difference is that this attack may be more likely to be attempted by larger criminal organization that have violent control over a population within a specific geography, whereas the other attack may be more likely to be attempted by individual criminals or smaller criminal organizations, but the safety features and the technical nature of the attack is identical.

An attacker could threaten to harm anyone that attempts to buy or sell bitcoin.

If an attacker can make it impossible to buy or sell bitcoin he wouldn't have to force existing investors to sell or hand over bitcoin because an asset that can't be sold can't become money.

Safety Features

No Impact to Adoption

Past Attacks

Bitcoin Merchants

In order for Bitcoin to become electronic cash (including a unit of account) merchants, that sell goods or services, must accept bitcoin for payment. If an attacker can prevent merchants from accepting bitcoin he would prevent Bitcoin from becoming cash.

An attacker could threaten to harm anyone accepting bitcoin as payment.

An attacker could threaten merchants with direct violence or they could tell merchants that they must perform free labor or pay money, if they accept bitcoin in order to prevent Bitcoin from becoming cash (including the unit of account).

Safety Features

Medium Risk

Past Attacks

Bitcoin Developers

Bitcoin developers are critical for the continued improvement of Bitcoin software. Without Bitcoin developers the Bitcoin code would not be improved and could become unusable if vulnerabilities discovered in the future are not repaired.

An attacker could threaten to harm anyone contributing to Bitcoin software.

If an attacker could convince developers that contributing to Bitcoin is likely to result in their death or kidnapping it is possible that Bitcoin would fail to become cash.

Safety Features

Past Attacks

No Impact to Adoption

An attacker could bribe or extort a Bitcoin developer into introducing a security flaw into Bitcoin.

If an attacker could get flawed code into the next version of Bitcoin he could destroy the features of Bitcoin that make it useful as money.

Safety Features

Past Attacks

No Impact to Adoption

Bitcoin Hardware Manufacturers

Bitcoin hardware manufactures produce hardware for mining. This mining hardware is critical for confirming Bitcoin transactions.

An attacker could threaten to harm Bitcoin mining hardware manufacturers if they sell to the public.

If cutting edge Bitcoin mining hardware was no longer available it would make confirming transactions less secure. This could reduce the security of Bitcoin enough to prevent it from becoming cash.

Safety Features

Past Attacks

No Impact on Adoption