Emulator exits prematurely if countermeasure 3 is activated

[oisonan1999]

I ran the project with RAP enabled and RAP not enabled. But when I look at the results after running, I am extremely confused because of the results given, parameters such as AttackSucces: True, ShadowPeerCount: 10,... (You can see more clearly in the txt file). And when countermeasures are enabled, the emulator will run shorter (specifically 30 days). I looked at the code and found that if shadow_outbound_peer_cnt >= m_max_outbound the attack is successful, but now after enabling RAP and disabling all countermeasures shadow_outbound_peer_cnt is still equal to m_max_outbound. Can you explain why is that so? Thank you very much!! l3-amzn copy.txt l3-amzn.txt

[akshayeshenoi]

In this case, when RAP was enabled in l3-amzn.txt, the attack lasted longer - 260 days vs 219 days when RAP was disabled in l3-amzn copy.txt.

This shows that the RAP defense can help delay the attack success, but not completely prevent the attack (Section 5.3: How (in)effective is RAP?).

I looked at the code and found that if shadow_outbound_peer_cnt >= m_max_outbound the attack is successful, but now after enabling RAP and disabling all countermeasures shadow_outbound_peer_cnt is still equal to m_max_outbound.

shadow_outbound_peer_cnt will be equal to m_max_outbound if the attack is successful. This can happen even if RAP is enabled.

In your case, I can see that the only difference between the two runs was that RAP was enabled in one and not the other. You can toggle the other countermeasures as well in cfg.py (cfg.CounterMeasures).

Enabling them may help delay the attack success even further. If the emulation exceeds 381 days, we consider the attack to fail.

[oisonan1999]

But when I turned on the flags in the cfg.py file, I noticed that the simulation time only lasted 30 days. In case of turning off RAP, the number of ShadowPeerCount is still smaller than OutboundPeerCount and AttackSucces: True. Why is that?. Can you help me explain? Thank you so much

[akshayeshenoi]

I see, there seems to be a bug here. Countermeasure 3 increases the number of outgoing connections to make it harder for the adversary to occupy all connections. Specifically, we increase only the outbound block relay connections m_max_outbound_block_relay.

Unfortunately, m_max_outbound—which is the sum of full relay plus block relay connections—wasn't reflecting the increase causing the emulation to end prematurely.

It's a simple fix, I will push it shortly. Thank you for bringing it up.

[akshayeshenoi]

FYI, I also noticed that you tweaked the victim_age param to 20 days. Note that this may make it easier for the attacker to succeed because the victim's database may have fewer tried connections.