No, it could not manipulate the RNG output, because phrases will be combined to one hash, which will be used for RNG.
Thank you for your answer and correct me if I'm wrong, but if server chooses seed AFTER receiving users' seeds than it can select one that creates specific hash.
In example, if server uses timestamps as a seed - it can wait some tiny period of time (few milliseconds) and, knowing users seeds, choose favourable timestamp to produce hash. It would be fair if server chooses a seed BEFORE receiving data from clients. But how could you prove that this is how it works if the poker client is not open-source? And there is another way of creating manipulated hash if the client is not open-source that I can think of: clients and servers communicating and cooperating to choose favourable seed.
I'm not conspiracy theorist and I like your project, but I'm concerned about this. If fair game is your selling point than verifying RNG alone is not enough. I don't see how you can prove that selecting seeds is fair.
RNG will depend on different phrases of each player and so the output number.
We know, it may sound complicated, but actually this is very elegant and pretty simple solution.
Let us take example:
Before hand starts:
Player-A, uses phrase: "apple"
Player-B, uses phrase: "banana"
Operator, used phrase: "orange+time_stamp", and in centralized server:
"apple" + "banana" + "orange+time_stamp" => combined together and used as a seed for random number generation, and so card is picked up, for instance "9h".
This is logged and sent to blockchain.
Now you can open this log (where all phrases was used and all numbers generated) and validate RNG (engine and RNG algorithm will be provided as one of the validation tools publicly).
You will take "apple", "banana" and "orange+time_stamp", make a hash (a tool and algorithm will be provided publicly as well) and then supply it for RNG to check what output is (in this case you will get same number as in log provided, which will match "9h").
So, how operator could compromise this process?
- phrases used in RNG could not be changed, users will notice it.
- RNG output could not be changed, users will check it's validation.
- server could try to guess it's own phrase, in combination of 'apple' + 'banana' + 'x' => hash => RNG => to get output needed (compromised). But here is a problem: 'x' will use mix of random_phrase+time_stamp, and so the roll back process: output_needed (compromised) => RNG => hash => all_phrases (with time predicted) will took decades or may not be possible at all.
We hope it is more clear now.