Thanks for chiming in. Your explanation about the "trilemma" that the system you have set up solves makes completely sense.
May you please explain a bit more in details PH offer more guaranteee to dice game ( what do you mean by atomic?) than crash?
Crash is actually quite a difficult to do well, because it's a "realtime" game, latency really matters. And because it's multiplayer, you have to keep progressing the game for everyone.
There's a demo here of how to do crash with ProvablyHonest (
https://github.com/provablyhonest/vx-demo/blob/master/crash.ts ) but basically the casino simply "finds out" what the bust is at the *start* of the game (in a way that is provably fair, and wouldn't allow PH to cheat). Then the crash game happens, and then casino reveals the information to PH to show they computed the outcome correctly.
So the main advantage here, is from the casinos point of view: They don't need to worry as much about storing a highly secret "master seed" that if ever was leaked/looked-at would compromise all their games. They only find out the outcome just at the start of the game. But they still need to keep that a secret during the actual game. It would be trivial for the casino to have a bug which leaked the crash-outcome during the game. And this bug could be maliciously entered by a hacker / compromised-employee / backdoor etc.
A more atomic game, like dice, however ProvablyHonest does a much better job at. (code eg.
https://github.com/provablyhonest/vx-demo/blob/master/dice.ts ). That is because the casino sends
all the bet information (who is betting, how much they're betting, what they're betting on) to PH
first and
then it gets the outcome. Then it verifies the outcome (to make sure PH is not cheating). This is a much "nicer" design, because the casino
never has a secret they need to store. They can't accidentally leak anything, because they never know it. Even if their software was compromised, the attacker can't really do anything that's not detectible.