Are there any fundamental security vulnerabilities in Bitcoin?



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?


Posted 2011-09-02T08:36:46.850

Reputation: 931



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.

Alex Waters

Posted 2011-09-02T08:36:46.850

Reputation: 3 101

2 has a listing of the potential downfalls of Bitcoin – Alex Waters – 2011-09-02T09:06:01.383

1Well, he came to the conclusion that there weren't any vulnerabilities other than the two he mentioned and the ones that were already known at the time (and that were accepted in the design phase). – David Schwartz – 2011-09-02T09:34:34.533

Here you can find a nice article about it:

– Felipe – 2012-11-14T02:27:53.617


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.

David Schwartz

Posted 2011-09-02T08:36:46.850

Reputation: 48 957


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).

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:

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):

Stephen Gornick

Posted 2011-09-02T08:36:46.850

Reputation: 26 454


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 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.


Posted 2011-09-02T08:36:46.850

Reputation: 529