Betroom is officially Provably Fair
I'm always interested in provably fair systems, but I don't see how this is remotely is. The first problem is there's a real lack of information/example (as in a concrete example specific to the game), which makes verification more or less impossible even if it was provably fair. But besides that, I don't even see how the method you are using even attempts to solve the problem.
So as I understand it, at a high-level you're trying to do something like:
* Server generates a server-seed
* Server gives clients a hash of the server-seed (to prove it doesn't change)
* Each clients provide the server a client-seed after they've seen the server-seed hash
And then the game result is computed as a function of (ServerSeed, ClientSeeds).
---
If I'm understanding right, that doesn't solve anything at all -- because if
any client was controlled by the server, it could pick a client-seed that will make it win.
--
The only way you're (sanely) going to get a game like this to be provably fair, is have each client have a secret -- send a hash of the secret to the server (which broadcasts to all other clients). Then when the client has seen the hash of all other clients seeds, reveals it's own seed. Then the game result is computed based on all the client seeds.
P.S. I'll PM you a security problem i (think i) found
P.P.S. How come your site says there's 470 people online? Surely that can't be real?
P.P.S. How come your site says there's 470 people online? Surely that can't be real?
We are running marketing large campaigns on many websites and get traffic all the time. "Online" means visitors, not users that are signed in.
P.S. I'll PM you a security problem i (think i) found
Solved that just now, thank you so much!
The only way you're (sanely) going to get a game like this to be provably fair, is have each client have a secret -- send a hash of the secret to the server (which broadcasts to all other clients). Then when the client has seen the hash of all other clients seeds, reveals it's own seed. Then the game result is computed based on all the client seeds.
This won t solve the problem neither. As i explained to my arch-enemy TwitchySeal, with this game in particular, since it s a reactive game, the server must know the result in advance, so this won t work either. Let me explain how the game is made so that you know the actual problem and then you might help me find a solution to this - i m referring to the Rocket Crash game.
1. Clients buy tickets to join the game.
2. Once there are at least 10 players that bought tickets for that event, the countdown starts.
3. In the mean time clients can choose the client seed and send it to the server.
4. Server computes server seed + client seed + nonce into one piece of string and the function generates the random number when the timer strikes zero.
5. This number is sent SEQUENTIALLY (unit by unit every tenth of a second) to clients because if the final value is sent, then with a small hack clients will know what the actual crash value will be.
6. Game starts and clients jump off the rocket IN REAL TIME.
The problem comes at "5" because the server MUST know the crash value BEFORE game start in order to divide it and send it unit by unit to the players. If players would not jump in real time, then yes, what you are saying is correct and could be implemented so that a result would not be known by any party before the actual event took place. In this particular case, the server does not
need to control the client seed since it "knows" the actual crash value in advance.
So, with this particular game, if you have a solution to it, please let me know and if it s real, i ll implement it.