6

What prevents someone from using a Precomputed POW Spam Attack against the network?

A theoretical attack could use pre-made transactions to be released before their network expiry dates.

Rounds of fictitious transactions can be created and post-dated two weeks to three weeks in the future within an internal database and tagged by expiry date. These can be formed into subtangles if desired.

For example, a person makes 2.5 million to 5 million pre-made transactions that can be harvested at the right time, before each transaction will no longer be accepted by the network.

A simple network graph is constructed and 5 or 6 IRI nodes are created to be part of the network as regular Field/Nelson nodes but with a few software tweaks to ensure that they also listen to a private master node and relay those transactions first.

Within the second generation 45 neighbors will be broadcasting. By the time it reaches the third generation, 320 neighbors will be gossiping. By the time it reaches the fourth or fifth generation, the entire network will be permeated.

The gossip makes it impractical to track the origin of bad transactions - the network has effectively self-obfuscated its own security backups.

I think that pretty much sums up the basics of what is needed for this to succeed.

People have asked something similar to this

Improve this question
5
  • I'm not sure from your description what tips you would choose for the "fictitious root transactions". As you cannot change those tips later without redoing all the PoW, I believe that not enforced timestamps are irrelevant for your attack scenario.Your cached transactions will (if I am not mistaken) be attached on tips that are 3 weeks old (from the alleged transaction time) so unlikely to be chosen by the tip selection of other nodes.
    – mihi ♦
    Commented Jun 1, 2018 at 20:50
  • Ah ok, you edited your question and you only want to DoS the network. I guess there are a lot easier ways to do that, though.
    – mihi ♦
    Commented Jun 2, 2018 at 11:35
  • Please help me understand something here. With Point number 1 in mind, is the gossip protocol forwarding spam TXs to other nodes without checking if the Branch and Trunk exist within the current Milestone timestamp? If that is so, is it a fix to just drop such TX from the cache, and wait for the "existing" branch to arrive first? Imagine that the node caches on a normal basis as good as it can, but unless the confirmed TXHash shows up, gossip of the spam does not happen. What could go wrong in that case? (really asking)
    – Makan
    Commented Aug 28, 2018 at 15:45
  • In such case it would be a nice closure if you mention the version of code with the fix and post it as an accepted answer. just a thought.
    – Makan
    Commented Aug 29, 2018 at 9:22
  • I see, thank you. Some small correction: With the suggestion i mentioned (only gossip the TXs with existing Trunk & Branch), you COULD still gossip transaction B before A, even though chronologically B is after A. The requirement for such event is that B does not directly or indirectly confirm A. I agree that this approach still limits the gossiping speed, however to me it sounds pretty intuitive / mature.
    – Makan
    Commented Aug 30, 2018 at 8:34

1 Answer 1

Reset to default
4

The attack you describe may overload your direct neighbors with useless transactions. This may impact the network locally, but to impact the network globally, you should have a huge amount of direct neighbors.

Internal queues in the IRI have a limited size to prevent this kind of attack (and "OutOfMemory" crash). As soon as the queues of your direct neighbors are full those useless transactions will be dropped and not even "gossiped".

Improve this answer
3
  • Recently, a spammer was spamming on about 150 neighbors (not sure of the exact number) in carriota-field and it caused real performance problems (almost zero ctps).
    – ben75
    Commented Jun 3, 2018 at 14:09
  • Receive and broadcast queues are also limited to 1000 txs by default. see Node.java line 350 and 643
    – ben75
    Commented Jun 3, 2018 at 14:12
  • Hi @ben75 it would be great if the additional information from the discussion could find their way into your answer.
    – Helmar
    Commented Jun 4, 2018 at 13:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.