Weaknesses

Might be a problem

Wallet Vulnerable To Theft

The wallet is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.

Tracing a coin's history

Tracing a coin's history can be used to connect identities to addresses. More info.

Cancer nodes

It's trivial for an attacker to fill the network with clients controlled by him. This might be helpful in the execution of other attacks.

For example, an attacker might connect 100,000 IP addresses to the IRC bootstrap channel. You would then be very likely to connect only to attacker nodes. This state can be exploited in (at least) the following ways:

• The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.
• The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks.
• If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.
• Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.

Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.

Looking for suspiciously low network hash-rates may help prevent the second one.

No authentication for IP transfers

Since there's no authentication when sending to an IP address (as opposed to a Bitcoin address), executing a man-in-the-middle attack and stealing the sent BitCoins is trivial. This attack is downright likely if you're using Tor. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.

Packet sniffing

Someone who can see all of your Internet traffic can easily see when you send a transaction that you didn't receive (which means that it's yours). This would be made more difficult (but not impossible) if node-to-node encryption was used.

Denial of Service (DoS) attacks

Sending lots of data to a node may make it so busy it cannot process normal bitcoin transactions. Bitcoin has some denial-of-service prevention built-in, but is likely still vulnerable to more sophisticated denial-of-service attacks.

These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:

1. Does not forward orphan transactions/blocks
2. Does not forward double-spend transactions
3. Does not forward the same block, transaction or alert twice to the same peer.
4. Restricts the maximum number of signature checks a transaction input may request
5. Continuous rate-limit of free transactions to mitigate 'penny-flooding'
6. Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.
7. Bans IP addresses that misbehave for a time lapse (24 hours default)
8. Limits the number of stored orphan transactions (10000 by default)
9. Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions
10. Limits the number of stored signatures in the signature cache (50000 signatures by default)
11. Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.
12. Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.
13. In orphan/signature caches, when removing an item, evicts a random entry.
14. Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.
15. Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.
16. In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.
17. In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.
18. In GUI: Limits URI length to prevent a DoS against the QR-Code dialog

Satoshi client does not directly limit peer bandwidth nor CPU usage.

Forcing clock drift against a target node

See Timejacking for a description of this attack. It can be fixed by changing how nodes calculate the current time.

Illegal content in the block chain

It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.

Security Vulnerabilities and bugs

It's possible but unlikely that a newly discovered bug or security vulnerability in the standard client could lead to a block chain split, or the need for every node to upgrade in a short time period. For example, a single malformed message tailored to exploit a specific vulnerability, when spread from node to node, could cause the whole network to shutdown in a few hours. Starting from version 0.7.0, Bitcoin client can be considered a mature project. The security critical sections of the source code are updated less and less frequently and those parts have been reviewed by many computer security experts. Also Bitcoin Satoshi client has passed the test of being on-line for more than 3 year, without a single vulnerability being exploited in the wild. See Common_Vulnerabilities_and_Exposures for a detailed list of vulnerabilities detected and fixed.

Probably not a problem

Breaking the cryptography

SHA-256 and ECDSA are considered very strong currently, but they might be broken in the far future. If that happens, BitCoin can shift to a stronger algorithm. More info.

Scalability

BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the scalability page for more information.

Segmentation

If there is even a "trickle" of a connection between two sides of a segmented network, things should still work perfectly. When block chains are combined, all of the non-generation transactions in the shorter chain are re-added to the transaction pool -- they'll start over at 0/unconfirmed, but they'll still be valid. No mature transactions will be lost unless the segmentation persists for longer than ~120 blocks. Then generations will start to mature, and any transactions based on those generations will become invalid when recombined with the longer chain. More info.

Attacking all users

The IP addresses of most users are totally public. You can use Tor to hide this, but the network won't work if everyone does this. BitCoin requires that some country is still free.

Dropping transactions

Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains "active" and can be included in a later block. Two things discourage this:

• Nodes only hash a fixed-size header, so there is no speed advantage to dropping transactions.
• Satoshi has communicated that he will write code to stop this kind of thing if it becomes a problem.

Attacker has a lot of computing power

An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:

• Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
• Prevent some or all transactions from gaining any confirmations
• Prevent some or all other miners from mining any valid blocks

The attacker can't:

• Reverse other people's transactions
• Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
• Change the number of coins generated per block
• Create coins out of thin air
• Send coins that never belonged to him

It's much more difficult to change historical blocks, and it becomes exponentially more difficult the further back you go. As above, changing historical blocks only allows you to exclude and change the ordering of transactions. It's impossible to change blocks created before the last checkpoint.

Since this attack doesn't permit all that much power over the network, it is expected that no one will attempt it. A profit-seeking person will always gain more by just following the rules, and even someone trying to destroy the system will probably find other attacks more attractive. However, if this attack is successfully executed, it will be difficult or impossible to "untangle" the mess created -- any changes the attacker makes might become permanent.

Spamming transactions

It is easy to send transactions to yourself repeatedly. If these transactions fill blocks to the maximum size (1MB), other transactions would be delayed until the next block.

This is made expensive by the fees that would be required after the 50KB of free transactions per block are exhausted. An attacker will eventually eliminate free transactions, but Bitcoin fees will always be low because raising fees above 0.01 BTC per KB would require spending transaction fees. An attacker will eventually run out of money. Even if an attacker wants to waste money, transactions are further prioritized by the time since the coins were last spent, so attacks spending the same coins repeatedly are less effective.

The Finney attack

Named for Hal Finney, who first described this variation of a double-spend attack involving accepting 0-confirmation transactions. Accepting 0-confirmation large-value transactions is problematic; accepting them for low-value transactions (after waiting several seconds to detect an ordinary double-spend attempt) is probably safe.

Rival/malicious client code

Any rival client must follow Bitcoin's rules or else all current BitCoin clients will ignore it. You'd have to actually get people to use your client. A better client that pretends to follow the same rules, but with an exception known only to the author (possibly by making it closed source), might conceivably be able to gain widespread adoption. At that point, its author could use his exception and go largely unnoticed.

Definitely not a problem

Coin destruction

Bitcoin has 2.1 quadrillion raw units, making up 8 decimals of BTC precision, so the entire network could potentially operate on much less than the full quantity of Bitcoins. If deflation gets to the point where transactions of more than 10 BTC are unheard of, clients can just switch to another unit so that, for example, it shows 10 mBTC rather than 0.01 BTC.

The maximum number of raw units might not be enough if the entire world starts using BTC, but it would not be too difficult to increase precision in that case. The transaction format and version number would be scheduled to change at some particular block number after a year or two, and everyone would have to update by then.

Generating tons of addresses

Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.

Also, a collision is highly unlikely.

Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power) Divide it by the world population and you have about 215,000,000,000,000,000,000,000,000,000,000,000,000 addresses per capita.(2.15 x 10^38)[1]

Everyone calculates at the same rate

If everyone began with identical blocks and started their nonce at 1 and incremented, the fastest machine would always win. However, each block contains a new, random public key known only to you in the list of transactions. The 256-bit "Merkle tree" hash of this is part of the block header.

So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).

Generate "valid" blocks with a lower difficulty than normal

Using unmodified Bitcoin code, an attacker could segment himself from the main network and generate a long block chain with a lower difficulty than the real network. These blocks would be totally valid for his network. However, it would be impossible to combine the two networks (and the "false" chain would be destroyed in the process).

• Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.
• Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.
• "Block chain length" is calculated from the combined difficulty of all the blocks, not just the number of blocks in the chain. The one that represents the most CPU usage will win.

See Also

• Double-spending