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

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

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

CC BY-SA 3.0
2011-09-02T09:41:17.143Z
2011-09-02T09:41:17.143Z
David Schwartz
<p>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.</p>

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

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

<p>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: <a href="http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391" rel="nofollow">http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391</a></p>

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

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

<ul>
<li>Use some other ledger system or Open Transactions</li>
<li>Use an intermediary e.g., Instawallet's Green Address: <a href="http://bitcointalk.org/index.php?topic=32818.0" rel="nofollow">http://bitcointalk.org/index.php?topic=32818.0</a> or Mt. Gox redeemable code (voucher).</li>
</ul>

CC BY-SA 3.0
2011-09-02T18:37:44.483Z
2011-09-02T18:37:44.483Z
Stephen Gornick
<p>This is an update, as of NOV-2012, since the answers are outdated.</p>

<p><strong>Are there any vulnerabilities right now?</strong> </p>

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

<p><strong>Were there any in the past?</strong></p>

<p>Yes, check <a href="https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures" rel="nofollow">https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures</a> 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.</p>

CC BY-SA 3.0
2012-11-13T21:48:46.230Z
2012-11-13T21:48:46.230Z
SDL
<p>As David Schwartz said in <a href="https://bitcoin.stackexchange.com/questions/367/have-any-crypotography-experts-vetted-the-bitcoin-source-code">367</a>; 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.</p>

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

CC BY-SA 3.0
2012-11-14T02:27:53.617Z
Here you can find a nice article about it: http://codinginmysleep.com/bitcoin-attacks-in-plain-english/
Felipe
CC BY-SA 3.0
2011-09-02T09:06:01.383Z
https://en.bitcoin.it/wiki/Weaknesses has a listing of the potential downfalls of Bitcoin
Alex Waters
CC BY-SA 3.0
2011-09-02T09:34:34.533Z
Well, 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
CC BY-SA 3.0
2011-09-02T09:04:24.817Z
2011-09-02T10:02:49.540Z
2017-04-13T12:47:33.743Z
Alex Waters
<p>Although Bitcoin does its best to prevent double-spending, could it still happen in practice?  Is it just <em>very unlikely</em> that fraud could happen, or is there a mathematical proof that it could never happen?</p>

<security><fraud>
Are there any fundamental security vulnerabilities in Bitcoin?
Jez
# Are there any fundamental security vulnerabilities in Bitcoin?

(Asked by: username_0 on 2011-09-02)

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?

**Tags:** security, fraud


---

## 4 answers

### Answer by username_4 on 2011-09-02. Score: 18 | Accepted answer

As username_1 username_1 said in [367](https://bitcoin.stackexchange.com/questions/367/have-any-crypotography-experts-vetted-the-bitcoin-source-code); 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.

> **Comments:**
> **username_4**: https://en.bitcoin.it/wiki/Weaknesses has a listing of the potential downfalls of Bitcoin  
> **username_1**: Well, 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).  
> **username_5**: Here you can find a nice article about it: http://codinginmysleep.com/bitcoin-attacks-in-plain-english/  

---

### Answer by username_1 on 2011-09-02. Score: 5

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 by username_2 on 2011-09-02. Score: 4

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 by username_3 on 2012-11-13. Score: 2

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.


---

