<p>The 0.6 release includes fixes for a couple of denial-of-service vulnerabilities, including this one (see <a href="https://github.com/bitcoin/bitcoin/commit/142e604184e3ab6dcbe02cebcbe08e5623182b81" rel="nofollow">commit 142e6041</a>).</p>

<p>Disconnecting peers that send "too many" orphans might be implemented in a future release.</p>

<p>In the future, if you find a DoS or security vulnerability in a Bitcoin implementation it is best to email the developer or developers so they know about the problem as soon as possible.</p>

CC BY-SA 3.0
2012-03-07T13:44:09.710Z
Sorry, I noticed a (possible) flaw was present in the code after writing the question.
SDL
CC BY-SA 3.0
2012-03-07T13:54:00.213Z
I'd be delighted if you post a simple thanks line in the Bitcoin release log!
SDL
CC BY-SA 3.0
2012-03-05T15:06:07.333Z
2012-03-05T15:06:07.333Z
gavinandresen
<p>I´m asking this because a possible attack would be to send an flooding number of orphan transactions, which will never be redeemed. Then clients would have to cache them, increasing storage requirements and reducing lookup time. This can lead to a resource-exhaustion attack.</p>

<p>If there is a limit on the size of the cache, then a DoS can be mounted to exhaust the limit.
In both cases, a DoS attack can be mounted.</p>

<p>If there is no protection, adding a proof-of-work to each transaction would help to prevent such attack.</p>

CC BY-SA 3.0
2012-02-10T13:02:02.133Z
What cache are you referring to?
ripper234
CC BY-SA 3.0
2012-02-10T13:25:21.790Z
I went to the Bitcoin sourcecode for reference. See main.cpp: mapOrphanTransactions. Transactions are added by AddOrphanTx(). There is no limit on the number of orphan transactions that can be inserted in mapOrphanTransactions. The question is therefore: is a DoS attack possible?
SDL
CC BY-SA 3.0
2012-02-10T13:49:53.353Z
Also mapOrphanTransactionsByPrev could be attacked, but the fact that c++ map lookup is O(N logN) may prevent the attack to be effective.
SDL
CC BY-SA 3.0
2012-02-10T15:29:48.313Z
While it's O(N log N) but you could fill the machine's memory with a DDoS attack sending a significant number of trx. Am I missing something?
usr-local-ΕΨΗΕΛΩΝ
CC BY-SA 3.0
2012-02-10T19:06:28.850Z
@SDL "c++ map lookup is O(N logN)".  I find that hard to believe.  A linear search through the elements would be O(N), which is cheaper than the o(N log N) you suggest.  Perhaps you meant to write "is O(log N)".  (See also http://en.cppreference.com/w/cpp/container/map where it says "Search, removal, and insertion operations have logarithmic complexity").
Chris Moore
CC BY-SA 3.0
2012-02-11T00:19:43.720Z
Sorry! Yes, I meant O(LogN) not O(NLogN).
SDL
CC BY-SA 3.0
2012-02-11T11:22:36.043Z
How would exhausting the limit result in an attack of any kind? Throwing away orphaned transactions doesn't cause any harm. Anyone who cares about them can introduce them when they're no longer orphans, and if nobody cares about them, well ...
David Schwartz
CC BY-SA 3.0
2012-02-12T22:51:37.957Z
If you throw away orphan transactions you throw away the possibility of overlapped transactions. So you end up being able to do 1 payment every 6 blocks (for each account), not faster than that.
SDL
<transactions><cache>
Is there a limit on the number of orphan transactions a node can cache?
SDL
# Is there a limit on the number of orphan transactions a node can cache?

(Asked by: username_0 on 2012-02-10)

I´m asking this because a possible attack would be to send an flooding number of orphan transactions, which will never be redeemed. Then clients would have to cache them, increasing storage requirements and reducing lookup time. This can lead to a resource-exhaustion attack.

If there is a limit on the size of the cache, then a DoS can be mounted to exhaust the limit.
In both cases, a DoS attack can be mounted.

If there is no protection, adding a proof-of-work to each transaction would help to prevent such attack.

**Tags:** transactions, cache

> **Comments:**
> **username_1**: What cache are you referring to?  
> **username_0**: I went to the Bitcoin sourcecode for reference. See main.cpp: mapOrphanTransactions. Transactions are added by AddOrphanTx(). There is no limit on the number of orphan transactions that can be inserted in mapOrphanTransactions. The question is therefore: is a DoS attack possible?  
> **username_0**: Also mapOrphanTransactionsByPrev could be attacked, but the fact that c++ map lookup is O(N logN) may prevent the attack to be effective.  
> **username_2**: While it's O(N log N) but you could fill the machine's memory with a DDoS attack sending a significant number of trx. Am I missing something?  
> **username_3**: @username_0 "c++ map lookup is O(N logN)".  I find that hard to believe.  A linear search through the elements would be O(N), which is cheaper than the o(N log N) you suggest.  Perhaps you meant to write "is O(log N)".  (See also http://en.cppreference.com/w/cpp/container/map where it says "Search, removal, and insertion operations have logarithmic complexity").  
> **username_0**: Sorry! Yes, I meant O(LogN) not O(NLogN).  
> **username_4**: How would exhausting the limit result in an attack of any kind? Throwing away orphaned transactions doesn't cause any harm. Anyone who cares about them can introduce them when they're no longer orphans, and if nobody cares about them, well ...  
> **username_0**: If you throw away orphan transactions you throw away the possibility of overlapped transactions. So you end up being able to do 1 payment every 6 blocks (for each account), not faster than that.  

---

## 1 answers

### Answer by username_5 on 2012-03-05. Score: 3 | Accepted answer

The 0.6 release includes fixes for a couple of denial-of-service vulnerabilities, including this one (see [commit 142e6041](https://github.com/bitcoin/bitcoin/commit/142e604184e3ab6dcbe02cebcbe08e5623182b81)).

Disconnecting peers that send "too many" orphans might be implemented in a future release.

In the future, if you find a DoS or security vulnerability in a Bitcoin implementation it is best to email the developer or developers so they know about the problem as soon as possible.

> **Comments:**
> **username_0**: Sorry, I noticed a (possible) flaw was present in the code after writing the question.  
> **username_0**: I'd be delighted if you post a simple thanks line in the Bitcoin release log!  

---

