What is "dice1" and "dice2"? I assume your and your opponent's result, right? So:
1) How is it possible that you show the hash already before I join a game? My opponent's result cannot be known yet?
2) How is it possible that: "
Each player will have a unique hash" if it's player vs player where both players would have the same result/rolls?
Besides this, it's still not provably fair.. it's very easy for you to just generate hashes that ensure that the opponent (which could be a "site-player") has a higher roll result.
Just because you "hash" things, doesn't make it provably fair.A proper P2P provably fair implementation should work like this:
1) Both players join a game (player 1 is who started game, player 2 who accepted game).
2) Both players send a hashed version of their clientseed that was generated randomly in their browser with a cryptographically secure RNG.
3) After receiving the opponent's hashed clientseed (and showing it to the player - ideally with some seconds to copy it), they send their clientseed but now unhashed.
4) Site can already calculate result based on that.. for example use some HMAC function to generate a hash based on both clientseeds (player 1 is key, player 2 is message) and loop 2 dice results out of that (first roll is player 1, second is player 2.) A bit like regular dice games.
5) Send result + unhashed clientseeds to both players. They now know the result and can calculate the results themselves (and should be done automatically in browser too.)
This way, you - as site owner - cannot "pretend" to be a player and cheat. Therefor it is actually provably fair.
PS, I absolutely do not accuse you of cheating.. just to be clear
But if you have a provably fair implementation, it should be really provably fair. GL.