7

In the IRI, there is code designed to randomly drop TCP/UDP packets and/or to randomly thwart the data from TCP/UDP packets from being processed.

Given that this is a random application to all data, from any peers, how does this help?

What is the benefit to the node or the network?

In the UDPReceiver:

if(rnd.nextDouble() < P_DROP_TRANSACTION){
     break;
}

And here in the FIFO cache in Node:

private final double dropRate;
private final SecureRandom rnd = new SecureRandom();
public V get(K key) {
    V value = this.map.get(key);
    if (value != null && (rnd.nextDouble() < this.dropRate)) {
        this.map.remove(key);
        return null;
    }
    return value;
}

To clarify, I am not asking about what the 'intended' benefit is so much as the actual benefit supported by evidence (an empiracle answer please).

As @ben75 commented below, there may be a variety of imagined reasons:

1) it make the network resilient to packet dropping attack from the start (it's already build in). 2) It introduce unpredictability and so make it more robust against coordinate attacks. 3) And third point (more speculative): imperfection in the network increase confirmation speed in case of double-spend resolution.

Just an attempt to clarify my point 3). Dropping random messages will make even more difficult for an attacker (having the goal to block the tangle by double-spending) to maintain the equilibrium of conflicting tangle branches. I agree that it's a very short explaination, and more based on my global perception of the consensus than on facts and measures. That's why I just put it a comment. (I will try to expose this point in more details in an answer when I have more time).

Those might or might not be the reasons why it is done. If they are the actual reasons the developers did this, then I would like to know what evidence supports that method.

For example:

(1) "it make the network resilient to packet dropping attack from the start (it's already build in)."

This can be done on the test network or done for a limited time on a live net. Regardless, this might not be a benefit unless there is evidence that this practice works, here or on other networks. What evidence is there that this a good strategy? Does dropping random packets make any network more resilient? Is this a recognized practice?

(2) "It introduce unpredictability and so make it more robust against coordinate attacks." Again, is this a recognized strategy? Does this work? Since it applies the unpredictability to good data and bad data, does it in fact do anything beneficial?

(3) "imperfection in the network increase confirmation speed in case of double-spend resolution." This sounds like a repeat of #2. How does this increase confirmation speed if the random packets dropped are those that might be good packets and further the attackers double spend?

I am not a network professional and have never heard of this strategy. I am very interested to confirm why this was done and also to know what evidence supports this strategy.

  • Just a guess: 1) it make the network resilient to packet dropping attack from the start (it's already build in). 2) It introduce unpredictability and so make it more robust against coordinate attacks. 3) And third point (more speculative): imperfection in the network increase confirmation speed in case of double-spend resolution. – ben75 Feb 24 '18 at 10:25
  • Just an attempt to clarify my point 3). Dropping random messages will make even more difficult for an attacker (having the goal to block the tangle by double-spending) to maintain the equilibrium of conflicting tangle branches. I agree that it's a very short explaination, and more based on my global perception of the consensus than on facts and measures. That's why I just put it a comment. (I will try to expose this point in more details in an answer when I have more time). – ben75 Feb 24 '18 at 14:42
3

The transaction dropping is a test code: the corresponding commit has the description "added random transaction dropping for testnet simulation". With the default configuration options it does not cause any transactions to be dropped, since the value of P_DROP_TRANSACTION is set to zero.

The cache is a different story. This configuration value is set to 0.02 by default, which means every time a cached entry is referenced, it has 2% probability of being dropped. This might be an attempt to devise a hybrid cache replacement policy that is the intermediate between FIFO and a completely random replacement - both of which are industry standard. According to this commit, it looks like they were using the LRU (least recently used) policy before this one, so there just seems to be a lot of experimentation going on wrt to finding the best one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy