[DuskStar]

Assuming you mean the attack where one person can wait to be the last to reveal their secret and then influence the game by dropping out, it doesn't appear to.

> What if someone loses network before the secret stage?

> A bad actor can't change the outcome of a flip but could prevent it from resolving.

> The Keybase app will highlight this scenario. Odds are it was just a network issue, but if you have such a person disappearing often, you should break up with them.

So someone with a malicious client could force the flip to not resolve until it creates an outcome they're satisfied with, which is... Not great. I can't tell if "The Keybase app will highlight this scenario" means it'll abort the roll or if it'll automatically reroll.

[leetbulb]

One way to solve this issue is to shuffle the possible outcomes and encrypt or hash their positions along with a nonce. This info would be distributed to clients during the game initialization. At reveal time, the server presents these outcome positions to the clients along with the other client secrets.

Also see my other comment in this thread where in a client/server architectured version of this protocol, the reveal step is split up in to two stages:

> 4a. All members submit their secret values to the server.

> 4b. Once all secret values are submitted, they are all sent to each member at once.

> This ensures that members cannot determine the outcome before anyone else.

[DuskStar]

Makes sense to me!

Even requiring a deterministic reveal order (without a central, independent server) would reduce the chance an individual could force a reroll after knowing the outcome from 1/1 to 1/n, which would be significant. The 'central server' solution is probably more relevant for Keybase though.