Re: Breaking: Shuffle-based Provably Fair Implementations Can Cheat Players (proof)
Nice work! But I think you're missing out the most interesting part, in a game of X how much can this exploit raise the house?
Thanks! More results to follow. The code is in the wild, I suspect someone will rewrite it to conform to the reference implementation. I'll reveal the arrangements I found and the raised house edge here soon. Since they're "drop in" exploits, a casino can deploy them immediately, and I don't want to be the direct cause of players getting cheated.
I actually did hit the modulo bias quite often, since I'm searching the entire space. I think it's silly that bitZino even had a modulo bias. It's a casino.
Quick and easy fix:Adapted from (https://stackoverflow.com/questions/10984974/why-do-people-say-there-is-modulo-bias-when-using-a-random-number-generator)
Code:
const RAND_MAX = 0xFFFFFFFF
function random() {
let x
do {
x = rand_int32() // use crypto.randomValues or something tied to a csprng
} while (x >= (RAND_MAX - RAND_MAX % n))
return x % n
}
function random() {
let x
do {
x = rand_int32() // use crypto.randomValues or something tied to a csprng
} while (x >= (RAND_MAX - RAND_MAX % n))
return x % n
}
A player may actually hit the modulo bias quite often for some games, such as blackjack, since it requires 314 random numbers per round of 8-deck. The Fisher-Yates shuffle actually requires a uniform random distribution to result in non-biased shuffles. An extreme example: shuffle a deck but always use the number 5 as the random number.