Re: ✅ Paradice.in | 🍀 Provably Fair 🎲 | Rain☔| 30 sec Faucet | 1% House Edge
Users are only able to set their own client seed string. The server seed is generated by the server, not by the user.
The nonce doesn't appear to be random. During the games I played, it is incremented in sequence from 0 after every seed refresh. At which point does the nonce become random?
The user is only allowed to choose between refreshing both seeds, or only the server seed within a 10 minute window.
Changing the client seed string will automatically generate a new server seed, and push it into the queue.
Choosing to advance the server seed queue will generate and queue a new server seed, without being given the option to change the client seed string, effectively locking both client and server seeds for 10 minutes.
Some areas for improvement if you wish to hold true to the claim of "Provably Fair":
1. Locking-in the client seed when choosing to advance the server seed queue.
> The server would already have the client seed before choosing this option. Without being given the option to change their client seed after choosing to advance the server seed queue, the server has the client seed at the time of creating the next queued server seed. Even if the nonce was random between 1-100, at this moment the server has the resources and variables needed to pre-compute outcomes.
2. Users may only refresh their seeds every 10 minutes.
> This appears to be an attempt at hoping the client forgets which seeds were changed 10 minutes ago, and choosing to advance the server seed queue instead of changing their client seed string. If true, this will move the server seed in the "next" position into current use. That seed was created while the server knows the client seed string (because 1, changing client seed will automatically generate a new "next" server seed; and 2. the client seed is unable to be changed after advancing the server seed queue).
3. Users must advance the server seed queue in order to verify their rolls.
> By doing this, the user is not able to change their client seed string again for another 10 minutes. This also appears to be a method designed to cause the server seed, created while the client seed was known to the server, to be moved from the next position into the current position.
4. Lack of transparency regarding the seed's creation.
> The server seed, not the hash of the seed, appears to be another hash output: a 64 character hexadecimal string. Doing a quick query with online hash identifier tools confirms the hash is made with SHA256. Meaning, the seed is also a hash. Hashes need input to be created, what was the original input of the seed before it was hashed and used as the seed?
For a truly "provably fair" system, the user should be allowed to change their client seed immediately after being served with a new server seed hash. The user would also be allowed to refresh their seeds at any time without limit. The actual server seed would also be known to the user, rather than a hash output.
Because of these issues, there is reasonable doubt the server is not pre-computing outcomes with unfavorable bias for players.
Quote
https://paradice.in/faq
Combination = Server Seed (can be generated by user) + Client Seed (can be changed by user) + Nonce (random 1-100)
[...]
Seeds can be changed by players, but only once per 10 minutes.
Combination = Server Seed (can be generated by user) + Client Seed (can be changed by user) + Nonce (random 1-100)
[...]
Seeds can be changed by players, but only once per 10 minutes.
The nonce doesn't appear to be random. During the games I played, it is incremented in sequence from 0 after every seed refresh. At which point does the nonce become random?
The user is only allowed to choose between refreshing both seeds, or only the server seed within a 10 minute window.
Changing the client seed string will automatically generate a new server seed, and push it into the queue.
Choosing to advance the server seed queue will generate and queue a new server seed, without being given the option to change the client seed string, effectively locking both client and server seeds for 10 minutes.
Some areas for improvement if you wish to hold true to the claim of "Provably Fair":
1. Locking-in the client seed when choosing to advance the server seed queue.
> The server would already have the client seed before choosing this option. Without being given the option to change their client seed after choosing to advance the server seed queue, the server has the client seed at the time of creating the next queued server seed. Even if the nonce was random between 1-100, at this moment the server has the resources and variables needed to pre-compute outcomes.
2. Users may only refresh their seeds every 10 minutes.
> This appears to be an attempt at hoping the client forgets which seeds were changed 10 minutes ago, and choosing to advance the server seed queue instead of changing their client seed string. If true, this will move the server seed in the "next" position into current use. That seed was created while the server knows the client seed string (because 1, changing client seed will automatically generate a new "next" server seed; and 2. the client seed is unable to be changed after advancing the server seed queue).
3. Users must advance the server seed queue in order to verify their rolls.
> By doing this, the user is not able to change their client seed string again for another 10 minutes. This also appears to be a method designed to cause the server seed, created while the client seed was known to the server, to be moved from the next position into the current position.
4. Lack of transparency regarding the seed's creation.
> The server seed, not the hash of the seed, appears to be another hash output: a 64 character hexadecimal string. Doing a quick query with online hash identifier tools confirms the hash is made with SHA256. Meaning, the seed is also a hash. Hashes need input to be created, what was the original input of the seed before it was hashed and used as the seed?
For a truly "provably fair" system, the user should be allowed to change their client seed immediately after being served with a new server seed hash. The user would also be allowed to refresh their seeds at any time without limit. The actual server seed would also be known to the user, rather than a hash output.
Because of these issues, there is reasonable doubt the server is not pre-computing outcomes with unfavorable bias for players.
With all due respect, this comment doesn't appear to be mathematically correct.
HMAC and SHA-2 are standard functions. So please don't mess the impression you have with the real principle of random algorithms.
But thank you any way. I will pass your ideas to Paradice management, because the sky is the limit!
