What happens to bond of challenger if there's no response?

[simondlr]

When challenging an invalid history (challengeBefore), a challenger has to submit a bond.

When finalizing the exit and it is still in CHALLENGED state, the bond of the exitor is transferred to the challenger, but the combined bond is never freed?

Shouldn't it be freed for posting the challenge?

Additionally, if it's the case the bond should be freed, doesn't this introduce a griefing vector? Anyone can challenge any exit JUST before the challenge period is over without providing enough time to respond, resulting the exitor's bond being slash and the challenger just collecting the exitor's bond for "free"?

[gakonst]

When finalizing the exit and it is still in CHALLENGED state, the bond of the exitor is transferred to the challenger, but the combined bond is never freed? Shouldn't it be freed for posting the challenge?

Good catch, you are correct, the successful challenger should get both his bond back, and the faulty exitor's bond. This will be fixed in #104.

--

Regarding the griefing attack vector whereby a challengeBefore is submitted right before the exit is finalized without giving the exitor a chance to exit their coin, that's a good point, which I've also thought of before.

Solving this is a good discussion topic. Here's a possible solution: Extend the coin's exit time after challengeBefore by T, leaving enough time for respondChallengeBefore. This however allows an attacker to delay the exit of the coin indefinitely, at cost of BOND_AMOUNT each time, like a censorship attack at a constant griefing cost per censor.

Perhaps better parameterizing the BOND_AMOUNT can mitigate/reduce the danger of this. Another option, which I believe is probably unsafe, is making it so that challengeBefore can only be responded to once. I believe this adds another attack vector whereby an attacker can initiate an invalid exit, make a challengeBefore, and then respondChallengeBefore to their exit (perhaps by colluding with the operator), and make her coin unchallengeable, so I wouldn't recommend that.

Thoughts?

[smartcontracts]

My solution for this in MoreVP is to simply split the exit period into two distinct time periods of equal length. Challenges must be submitted in period 1, responses must be submitted before the end of period 2.

[gakonst]

OK this has been addressed by #106 . Contracts have been modified accordingly, and the testChallengeBefore.js tests have been refactored and updated to match this.

[gakonst]

Closing since the fix has been merged