7
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.
What cache are you referring to? – ripper234 – 2012-02-10T13:02:02.133
1I 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 – 2012-02-10T13:25:21.790
Also mapOrphanTransactionsByPrev could be attacked, but the fact that c++ map lookup is O(N logN) may prevent the attack to be effective. – SDL – 2012-02-10T13:49:53.353
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-ΕΨΗΕΛΩΝ – 2012-02-10T15:29:48.313
@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 – 2012-02-10T19:06:28.850Sorry! Yes, I meant O(LogN) not O(NLogN). – SDL – 2012-02-11T00:19:43.720
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 – 2012-02-11T11:22:36.043
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 – 2012-02-12T22:51:37.957