Challange Race Condition

[aleph-v]

This issue is being reported as part of the ongoing audit being conducted by Authio for Kyokan.
The methods challengeExit and challengeFeeMismatch are subject to a transaction order dependence/race condition vulnerability. If a member of the community transmits a call to challengeExit or challengeFeeMismatch then a malicious party can see that and transmit the same data to challengeExit or challengeFeeMismatch with a higher gas price and receive the exit bond. This has two consequences:
(1) It removes some of the incentive of the community to watch for bad behavior, since they won't get the bond reward.
(2) If a person wants to behave maliciously they can submit their malicious exit then wait to see if someone will notice. When a person submits a challenge they can then race it and receive their own bond back. This means that malicious parties can submit malicious exits and only risk losing gas fees.

[hamdiallam]

This is a good point and not something that could unfortunately be prevented from my understanding.

We can mitigate this however.

Right now, our exitBond is completely arbitrary and a way around this would be to send make the bond sufficiently high such that users could comfortably set a higher gasPrice.
1.) The malicious user would repeatedly lose money starting and challenging exits
2.) If the malicious user intercepts a challenge by choosing an even higher gasPrice, they would pay more, and the original caller would at least be refunded a majority of the gas due to the function reverting earlier(will reorder require statements)

This is not a profitable strategy.

[aleph-v]

This issue has a fairly standard way of being fixed which is a commit reveal hash challenge system. But more advanced systems like submarine swaps have also been suggested.

I will say that I don't think setting a higher exitBond will fix this. Firstly while persons who have validly produced a challenge can set a higher gas price, so can people who wish to steal the solution. Moreover systems with multiple attackers which create a feedback loop/racing war have been documented in DEXs and they continue to be a problem despite pushing the boundaries of profitability. In the end the result is the same, a reduction of rewards for persons who are behaving as intended [and conversely a potential reduction of penalty for bad actors when they win the race].

[hamdiallam]

A commit, reveal, hash system can definitely work to fix this issue.

It depends on the design choices of the deployer if they really want this. It can be considered okay that this race condition exits as long as challenges are occurring. Watchtower services are meant to always challenges even if the bonds are stolen. (we envision watchtower services are payed for by users through a subscription model that allows them to stay offline with high confidence. The subscriptions will be more than enough to cover any gas loss due to front running.