Quote from: Cratoon on Today at 04:10:49 AM

Quote from: lionproof on June 21, 2025, 07:51:42 PM

Users are only able to set their own client seed string. The server seed is generated by the server, not by the user.

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.

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!

Wink

Where, exactly, do you believe I made a mistake? I only get the impression of dismissal from you, considering there is no actual reply to my concerns.

When the server has been provided with the inputs used to generate a winning number: a nonce, and a client seed, it can then generate a new seed and calculate the outcomes of the hashes created from that server seed, client seed and nonce. During the moment when the server has the two random inputs, i.e: the client seed+nonce, it has full capability to generate hundreds of new server seeds, then pre-compute the outcomes, then decide whether or not it will bias towards winning outcomes or losing outcomes. Is this incorrect?

In other words,

Quote

1. To get a random number each time, the system combines your Server Seed , your Client Seed and Nonce (rate number):
Message = Client Seed:Nonce
2. Then, the HMAC-SHA-512 message is calculated, where your Server Seed is the secret, the result is a 128-character hexadecimal string:
Hash = HMAC-SHA512(Message, Server Seed)
3. The first 5 characters of this line are converted to decimal a number in the range 0 to 1,048,575 (16 ^ 5 - 1). If the resulting number is more than 1 million, for The calculation uses the following five characters, etc. (the process can be repeated up to 25 times).
In a very rare case ((48,576 / 1,000,000) ^ 25), when all 25 hash fragments over 1 million when translated to decimal number, the remaining 3 characters are used.
4. In Dice, the resulting number is divided by 10,000. your throw. Received quotient is used as the result of your dice roll.
5. In Roulette, the resulting number is divided by 37. The resulting remainder of the division is used as the dropped out number.

User selects a value between 2 and 98 to win. Over or under

Code:

local hmac_input = client_seed .. ":" .. nonce
local hmac_output = hmac(sha512, hmac_input, server_seed)

for i = 1, 25 do
local start = (i - 1) * 5 + 1
local chunk = hmac_output:sub(start, start + 4)
if #chunk < 5 then break end

local dec = tonumber(chunk, 16)
if dec and dec < 1000000 then
return dec / 10000
end
end

local fallback = tonumber(hmac_output:sub(-3), 16) or 0
return fallback / 10000

Is this incorrect? From my understanding it appears there is in fact many opportunities for the server to pre-compute biased outcomes. These are not hidden, however the answers to my questions in the last post are non-existent in your reply.

lionproof

Posts

Merits