Did you even read the description on just-dice? It literally specifies *exactly* how this is done:
We then take the first 5 characters of that hex string and convert them to a decimal integer (that will be in the range 0 through 1048575 (16^5-1)).
If it is less than 1 million, we divide it by 10,000 and use it as your dice roll. That is the case 96% of the time.
Otherwise we use the next five characters of the 128 character hex string, and repeat.
You will notice all the verifiers follow that exact procedure, to all arrive at the exact same rolls.
Going to ignore the first half of your message because its just you being smug and contradicting the lower half of your message.
(Seriously how are you still trying to argue about provably fair while I never said it was the problem?)
But yes! Perfect justdice quote, now we're getting somewhere!
So let me recapitulate, you're telling me that after all the security and provably fair mishmash, in the end, justdice uses the last 3 bytes of the hmac output, creates a number, and divides it by 10k? This part right here buddy, that you need to verify every time you want to trust a website.
Sure, im very sure justdice are legit. But you could EASILY, for example instead of divide by 10k and get the dice roll, you divide and substract 5 every time. Or use modulo to turn every nth number into a 0 bet... Oh and flash news, YOU WOULD GET THE SAME RIGGED OUTCOME EVERY TIME. So where can you check that they dont do this? You need to read the verifier source code.
If the verifier isnt open sourced, you cannot prove that the website isnt scalping the house edge. Even if it is open source, you need to verify that the part where the hex output becomes a bet roll is uniformly distributed on the target interval.