How does this address the last revealer problem?
> 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.
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.
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.