Are there any fundamental security vulnerabilities in Bitcoin?

Question

Although Bitcoin does its best to prevent double-spending, could it still happen in practice? Is it just very unlikely that fraud could happen, or is there a mathematical proof that it could never happen?

Answer 1

As David Schwartz said in 367; Dan Kaminsky has spent some time auditing the Bitcoin core . He is a respected security professional, and his opinion on these matters is highly regarded.

He came to the conclusion that there weren't any concerning security vulnerabilities, but scalability is something that will have to be tackled as the project grows. Essentially; nothing the developers didn't already know about.

Answer 2

The only known fundamental vulnerabilities are double-spending and 51% attacks, which are closely related. It doesn't seem likely that there are any significant unknown fundamental vulnerabilities, though of course there could be exploitable bugs in the client. (The underlying algorithms will get weaker over time, but that's not a problem.)

Double-spending can definitely happen. If someone controlled 51% of the network's hashing power, they could double spend at will. How much you actually have to worry about that is a tough question though.

A deeper question is whether these problems are truly fundamental or whether they could be worked around without changing the fundamentals of Bitcoin. To my knowledge, these are open research questions. Proposals have been made to reduce the impact of the 51% attack, but they introduce their own vulnerabilities that while harder to exploit have even more disastrous consequences (such as network states that are inconsistent, persistent, and require manual intervention -- and perhaps a de facto central authority -- to resolve). You can argue that with some of these suggestions, it's not Bitcoin anymore.

Answer 3

There are a number of attacks which have the potential to allow an attacker to double spend but none of them are successful when the recommended practice of accepting payment only when the transaction has six or more confirmations against it.

For instance if a merchant accepts payment immediately after 0/unconfirmed, a "race attack" can sometimes be successful at double spending by an unsophisticated attacker.

Additionally, there is the Finney attack which requires a little more effort (possible only when mining and has successfully solved a block). http://en.bitcoin.it/wiki/Weaknesses#The_.22Finney.22_attack

There is another attack that requires a little more sophistication where a merchant accepting even with 1/unconfirmed can easily find the funds lost due to a double spend: http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391

There are suggestions as to how most merchants can still accept payment immediately on 0/unconfirmed with minimal risk to a double spend occurring though they require some additional processes that have not yet been developed, tested and refined.

Additionally, there are other approaches to this problem so that there is no confirmation delays though their implementations are external and do not benefit from the decentralized architecture of Bitcoin (i.e., each requires trust given to some other party):

• Use some other ledger system or Open Transactions
• Use an intermediary e.g., Instawallet's Green Address: http://bitcointalk.org/index.php?topic=32818.0 or Mt. Gox redeemable code (voucher).

Answer 4

This is an update, as of NOV-2012, since the answers are outdated.

Are there any vulnerabilities right now?

Probably not. But a new vulnerability could be created by mistake in future versions of the standard client.

Were there any in the past?

Yes, check https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures and you will see that there has been many vulnerabilities fixed. Almost 50% of the nodes are still vulnerable to CVE-2012-4682 and CVE-2012-4683.