8

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.

Michael Folkson
  • 14,337
  • 3
  • 11
  • 45
SDL
  • 589
  • 1
  • 4
  • 8
  • What cache are you referring to? – ripper234 Feb 10 '12 at 13:02
  • 1
    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 Feb 10 '12 at 13:25
  • Also mapOrphanTransactionsByPrev could be attacked, but the fact that c++ map lookup is O(N logN) may prevent the attack to be effective. – SDL Feb 10 '12 at 13:49
  • 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-ΕΨΗΕΛΩΝ Feb 10 '12 at 15:29
  • @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 Feb 10 '12 at 19:06
  • Sorry! Yes, I meant O(LogN) not O(NLogN). – SDL Feb 11 '12 at 00:19
  • 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 Feb 11 '12 at 11:22
  • 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 Feb 12 '12 at 22:51

1 Answers1

3

The 0.6 release includes fixes for a couple of denial-of-service vulnerabilities, including this one (see commit 142e6041).

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.

gavinandresen
  • 3,360
  • 21
  • 23
  • Sorry, I noticed a (possible) flaw was present in the code after writing the question. – SDL Mar 07 '12 at 13:44
  • I'd be delighted if you post a simple thanks line in the Bitcoin release log! – SDL Mar 07 '12 at 13:54