Flawed Provably Fair Systems

[Namworld]

Basically, the issue is that many casinos provide a new server hash for each bet. (Which means AFTER the client seed is provided unless you change it before every bet, because otherwise they will know your seed from last bet).

This system of one server seed for each rolls allows each bet to be "verified" immediately after each bet, but it's bad because it is meaningless if the client seed isn't also changed afterward before the roll. Those system designs probably result from wanting to provide instant bet verification and poor understanding of what makes something provably fair. Verification is actually harder to do and more tedious, because it is only provably fair if the player changes seed before each roll. If you're labeled as provably fair, that's what you should be getting by default. Not something optional that isn't explained to you.

Here's a simplified explanation of cheating that could be done through such a system by a nefarious casino operator:

You know how x2 is either roll under 49.5 or over 50.5 for 1% house edge dice site? x99 payout is roll under 1 or roll over 99? The losing rolls are always in the middle of the 0-100 rolling range.

So since a new server seed is provided for each new bet, they could select their server seed assuming the client seed doesn't change and give numbers that tend toward the center of the range instead of being random. Here's what would happen.

1. Client changes the seed after each new server seed, before every bet. He doesn't know server seed, so seed he provides should give a random number. (Painfully tedious, few actually do it, but for those who do, provably fair.)
2. Client doesn't change his seed. All bets are rigged and he doesn't play with a 1% house edge. This would be impossible to be caught since the roll would still match the seeds.

- No, you wouldn't be able to cheat the casino, because the number would still be randomly over/under 50. It would just be closer to 50 than average. The number doesn't need to be on the opposite side such that you could counter it by switching over/under to abuse it. It just needs to be closer to 50 than random numbers would, creating more losses for players. No counter.
- No, you wouldn't be able to notice that the website, across all players, has a much higher house edge than 1% which is unlikely. It's easy to fill with fake "lucky" account to compensate for the actual players who are "unlucky" and have a credible total wager volume/profit. It's also easy to limit to large account/smart targeting.
- No, you wouldn't be able to notice that no actual players report winning, because even if they gave themselves a 2% or 3% house edge or targeted accounts doing large bets for a very large house edge, there would still be winners.

The point is, every player could verify all their bets, it wouldn't catch this kind of cheating.

Many dice games/casinos use such a flawed system. There should never be any scenario where server seed are generated after the client seed as it allows the casino to do selective seeding! If a player can play that way, the system is flawed, because it's possible to make a provably fair system where the player is always covered. Players don't need to choose between provably fair or spamming bets.

Just-Dice was a very good example of a correct implementation. You still had to change your client seed after receiving the server seed, but server seed stays the same, until you request it to be revealed to verify bets. At will verification, but you must not forget to then change your client seed. Get new server seed, THEN add your seed, then good to go to spam bets.

Coinroll is another good example, where a daily predisclosed secret is used for everyone. This make changing it after the fact very hard as it would impact all rolls for the day, plus the hash is provided upfront making it pretty much impossible to find another secret which matches the hash. Verification is delayed slightly but we believe this is the best method currently available. We also don't provide a default client seed. We use the client's last deposit tx, which means we don't even have the possibility to choose a default client secret that would be advantageous for the current daily secret. The only way Coinroll could cheat would be by providing rolls that don't match seeds. It makes it hard to cheat as this would be easily noticeable that some bets results are not right. Even if a casino did it for only 1% of players/bets, it would only need a few people tracking bets to start noticing. We also provide archives of all betting on Coinroll for public auditing.

A well designed provably fair system is supposed to make it possible and easy to spot fraud by the operator. A system where the player can either choose to be covered with tedious manual work (changing seed before each bet) OR bet at will without being able to check if bets are actually provably fair is not needed and pointless when players could be covered at all time with a system like Coinroll's or Just-Dice's.

Regards from Coinroll's staff

Please add your input to this thread to let casino operators know of your support for all crypto gambling venues to update their provably fair system and be bound to higher transparency standards. I would also recommend gambling list creators start demanding systems similar to Just-Dice's or Coinroll's for being listed as provably fair.

[1714145605]

1714145605

[1714145605]

1714145605

[1714145605]

1714145605

[dooglus]

Please add your input to this thread to let casino operators know of your support for all crypto gambling venues to update their provably fair system and be bound to higher transparency standards. I would also recommend gambling list creators start demanding systems similar to Just-Dice's or Coinroll's for being listed as provably fair.

I agree that the "provable fairness" offered by services which change the server seed for every bet is very hard to take advantage of as a player.

If I play at PrimeDice, Bitzino, prcdice, and probably many more, for every roll I make I have to:

1) make a note of the server seed hash for this roll
2) pick a client seed in an unpredictable fashion
3) make the bet, noting the number they rolled
4) verify that the hash of the published server seed matches the one in step 1
5) verify that the published server seed combined with my chosen client seed gives the roll I saw in step 3

That's a LOT of work. Almost nobody is going to bother doing it, and so for all practical intents and purposes the site isn't provably fair for the majority of people.

Compare the above 5 steps *per roll* to what a player at Just-Dice or CoinRoll would have to do per roll:

3) make the bet, noting the number they rolled

That's right - they can just spam their bets, keeping a record of the rolled numbers.

That is because the bulk of the work required to verify PrimeDice rolls has been moved to the very start and very end of play, not per roll.

At Just-Dice, steps 1 and 2 are done before you start play, and steps 4 and 5 are done after you finish a session. You verify all your rolled numbers in bulk, using a single pair of seeds.

At CoinRoll, step 1 is the same for every player (the site has a global server seed per day), step 2 uses your most recent deposit's txid (obviously out of the site's control (unless they use transaction maleability, I guess?)), and steps 4 and 5 can only happen at the end of the 24 hour period.

I think JD's system is better than CoinRoll's, since it puts control entirely in the hands of the player. He gets to reveal his server seed whenever he wants to and doesn't have to wait until midnight. But both systems are vastly better for the player than having to do all that tedious work for every bet you want to make.

[jurov]

2) pick a client seed in an unpredictable fashion

By the way, if this step involves clicking a button that in turn calls javascript Math.random() function then that's no good, too. It can end up badly like brainwallet.

[cwil]

1) make a note of the server seed hash for this roll
2) pick a client seed in an unpredictable fashion
3) make the bet, noting the number they rolled
4) verify that the hash of the published server seed matches the one in step 1
5) verify that the published server seed combined with my chosen client seed gives the roll I saw in step 3

That's a LOT of work. Almost nobody is going to bother doing it, and so for all practical intents and purposes the site isn't provably fair for the majority of people.

The argument I'd make is that this longer process allows for real time verification, which I find preferable.  People are either going to take advantage of provably fair functionality or they're not, and most of them are not.  Those who are taking advantage are either going to only make a few rolls and be done, so it hardly matters if there's a few extra steps involved, and I'd argue that it's unlikely they would return to see the server secret after 24 hours anyway, or they're going to automate the process, so again it doesn't matter if the process is longer or not.

The major problem I have with a daily secret type setup is that it exposes the site operator to risk should that list ever get out.  I agree that JD's system is a decent compromise, as at least bets can be verified every 10 rolls or so as opposed to every 24 hours.

[Namworld]

The argument I'd make is that this longer process allows for real time verification, which I find preferable.  People are either going to take advantage of provably fair functionality or they're not, and most of them are not.  Those who are taking advantage are either going to only make a few rolls and be done, so it hardly matters if there's a few extra steps involved, and I'd argue that it's unlikely they would return to see the server secret after 24 hours anyway, or they're going to automate the process, so again it doesn't matter if the process is longer or not.

The major problem I have with a daily secret type setup is that it exposes the site operator to risk should that list ever get out.  I agree that JD's system is a decent compromise, as at least bets can be verified every 10 rolls or so as opposed to every 24 hours.

The thing is those that want to use provably fair will not want to do the work for every single bet. They'll want to do it in batch. So why are players not simply covered at all time by a provably fair system? It's deceptive because a bet that might just not be provably fair will still show the same "provably fair" checking instructions, but not all bets will be provably fair, only those where the client seed was provided AFTER the server seed (which usually means not a lot of them). Easy for a casino operator to abuse by doing selective seeding, yet all bets would show roll as "correct" under that system, even if cheating was going on. That's why as far as I'm concerned, any system where server seed can be provided after a client seed is retarded.

It shouldn't involve extra work on every single bet. There is alternatives. Every player can be covered at all time. They can then later verify any bet at any time, easily, should they wish to do so. They can also run checks in batch on large samples. Someone could audit everyone's bets. You can verify after the fact if you got the right roll, even if you didn't take any step to get provably fair. If you're labeled as provably fair, that's what you should be getting by default. Not something optional that isn't explained to you.

(I think I'm going to use those two last lines for my main post.)

[cwil]

Any site that provides the secret hash after you've input your client seed does not meet the commonly accepted definition of provably fair.  Just to satisfy my curiosity, what sites do you have in mind that do this?  Feel free to answer in a pm if you don't want to disparage other casinos.

Personally, I seriously doubt that a casino would be able to exploit vulnerabilities in a properly implemented provably fair solution.  I think it's likely that the majority of people don't understand the system or how it works beyond maybe the basic knowledge that you should pick a complex seed derived from a high-entropy source, but I also think it doesn't matter so much.  The minority of people who do understand and are checking will notice exploitation and either report it to the community or exploit it themselves if they're able.  Either way, a cheating casino loses.

I think the bigger danger besides how the server seed is produced is a faulty implementation.  Take a look at the following verification javascript from a particularly infamous bitcoin casino:

Code:

var provablyFair = function () {
    return {
        restrict: "E",
        scope: {
            serverSeed: "@",
            clientSeed: "@",
            initArray: "="
        },
        templateUrl: "tpl/directives/provably-fair.html",
        link: function (a) {
            var b = function (a) {
                    var b = new window.jsSHA(a, "TEXT");
                    return b.getHash("SHA-256", "HEX")
                },
                c = function (a, b) {
                    for (var c = a.length, d = parseInt("ffff", 16) + 1, e = 0, f = a.length - 1; c > 0;) {
                        var g = new window.jsSHA("" + c + b, "TEXT"),
                            h = g.getHash("SHA-256", "HEX").substring(0, 4),
                            i = parseInt(h, 16) / d,
                            j = Math.floor(i * (f - e + 1) + e);
                        c--;
                        var k = a[c];
                        a[c] = a[j], a[j] = k
                    }
                    return a
                };
            a.verify = function () {
                a.clientSeed = "" + a.clientSeed, a.initialHash = b(a.serverSeed);
                var d = c(a.initArray, a.serverSeed),
                    e = c(d, a.clientSeed);
                a.finalArray = JSON.stringify(e)
            }
        }
    }
};

This particular game gives you a server seed hash, and when you place your bet, you provide a client seed.  After the bet, you are provided with the server seed.  That seems to be following the rules so far.  The problem here is that, like Bitzino, there is a third variable, the initial shuffle.  The initial shuffle is only disclosed upon looking up your betting history.  Obviously the server could change the initial shuffle in a favorable way in this system, and truly cheat the player in a completely undetectable way.  This is solely a problem with a faulty implementation.  I don't know that this casino is actually engaged in any kind of wrong doing, but the opportunity certainly exists.  An interesting thing about this case is that the server secret is actually exposed before a second round of betting.  This leads me to the conclusion that they are deliberately not exposing the initial shuffle, which seems fairly suspicious.  They could actually expose the server secret before the initial bet and without that initial shuffle, it still would not be exploitable.

Edit: I reread the parent post, and I understand your point.  You adequately countered nearly everything I've said.  I don't believe you're correct in that a per bet server seed can't be made provably fair, however.  This is again an issue of proper implementation.  See Bitzino's solution:

Code:

e.setRandomClientSeed = function () {
            var e, n, r = [];
            try {
                for (; r.length < 24;) e = new Uint8Array(8), crypto.getRandomValues(e), n = Math.floor(e[0] / 4), 62 > n && r.push(n)
            } catch (i) {
                for (var a = 0; 24 > a; a++) r.push(Math.floor(62 * Math.random()))
            }
            for (var o = [], a = 0; 24 > a; a++) n = r[a], n += 48, n > 57 && (n += 7), n > 90 && (n += 6), o.push(n);
            t("#client_seed_input").val(String.fromCharCode.apply(null, o))
        }

It uses a cryptographically secure function, picks a new seed for every bet, and doesn't communicate that seed to the server before the bet is placed.  This could certainly be countered by overwriting this function with a predictable seed generator, but that's easily detected.

I'm not saying that a semi-permanent server seed is a better or worse than a per bet server seed.  I think they both have strengths and weaknesses, but it is very possible to make both approaches work in a fair manner.

[Namworld]

Actually, isn't it kind of the same thing? If the user didn't verify the file he was served that generates random seeds, he can't go back after the fact to verify. But it would be a big improvement. Many casinos don't even have javascript that automatically generates a client seed. Such that server seed will change, but not client seed, unless done manually be the user.

A 24h global secret can be remembered by many and the last deposit tx ID as client seed makes it easy for anyone, even if they did no checks before starting to bet, to go back and check them. It also makes it easy for 3rd party to audit.

The initial shuffle is only disclosed upon looking up your betting history.  Obviously the server could change the initial shuffle in a favorable way in this system, and truly cheat the player in a completely undetectable way.

You mean there's places that have an undisclosed variable in the calculation, no hash of it, that is only revealed after the bet? That defeats the purpose now, doesn't it... It's as good as no system.

[cwil]

I'll be blunt here, you can't fix stupid.  There's a very good reason why provably fair only exists in the bitcoin gambling world.  Everyone else uses ISO 9001 certification of their games coupled with local regulations.  It's a lot simpler for some authority to say that the games are doing what they're supposed to do than to have to audit it yourself.  If you look at Las Vegas in particular, the NGC does an excellent job at keeping casinos honest.  The provably fair system was created because that certification is expensive, no one would probably have wanted to certify a bitcoin casino at the time, and we all hate centralized authority.  Bitcoin at its core is the epitome of libertarian ideals like self reliance.  Some smart people created this system and explained in technical and layman's terms how to use it.  A lot of other smart people have verified that this system works, when used properly.  People need to change their seeds when they bet, that's a part of the system.  In fact, if I'm remembering correctly, after JD switched to its currently system, I complained because I couldn't change my seed every bet.  It was still provably fair, and I could in fact arbitrarily change my nonce, but not being able to change my seed simply felt wrong.

I want to clarify, from the casino operator's point of view, I can think of many ways to exploit a per bet server seed type system.  I can think of fewer ways to exploit the system coinroll uses, but not zero.  From a player's point of view, I can counter all of those.  A player simply has to pick a good, unpredictable seed, and anything a casino operator is trying to pull in regards to its provably fair system collapses.

You mean there's places that have an undisclosed variable in the calculation, no hash of it, that is only revealed after the bet? That defeats the purpose now, doesn't it... It's as good as no system.

That's precisely my point, this is a real problem, a site with a system that presents itself as provably fair when it truly is not.  People not using a provably fair system correctly and exposing themselves to possible cheating is much less of a problem.  One of these issues is systemic, while the other is due to incompetence on the part of the player.  That is the key issue.

[Namworld]

No, the point is that some players rely on others/trust what they're told. Which means that provably fair system that relies on the user to change his seed for every bet is bad. It leaves many bets not covered at all, that could be cheated in a way impossible to detect after the fact. Once it's done, you can never come back and verify if the bet was provably fair. Why should it be a convoluted, per bet, manual step to turn each bet into provably fair, when they could all be covered by default?

[moreia]

This explains it then... now I know why I have more statistically accurate rolls on just-dice and coinroll than I do on other sites.
To bad Prime has the best sig rate, or else I'd be promoting CR or JD

[cwil]

As has been seen many times on these forums, bad actors are routed out.  People really don't have to understand the intricacies of why it's fair, so long as experts agree that it is fair.  I've personally weighed in on the PrimeDice issue.  It is open to exploitation.  As a part of that thread I posted some simple javascript that corrects that vulnerability.  People need to hold themselves accountable for everything they do.  People should research, ask questions, and listen to the community.  The community in general doesn't want to see people cheated, and we make efforts to prevent it.  Scam casinos get called out regularly, you can look at my post history for examples.  Still, at the end of the day, everyone is responsible for their own actions, and if that includes losing money due to a lack of due diligence, then they should own that and learn from it.

It is simply not valid to claim that per bet server seeds are intrinsically worse than site wide server seeds.  I will concede that more avenues exist to exploit a per bet server seed system, but only in a flawed implementation.  Site wide server seeds are plain harder to screw up.  A provably fair set up includes a server seed hash and initial shuffle if required, and unobfuscated client side code for determining a client seed.  This set up is no better or worse than coinroll's, other than the perk of being able to verify outcomes in real time.  Similarly, you could argue that the perk of your system is that the player doesn't have to change his client seed.  Additionally, there is no merit in claiming that per bet server seed processes are convoluted.  While that may be true on a per site basis, Bitzino, whom I consider the de facto standard on provably fair systems, has created a decidedly fair and simple system.  BitcoinVideoCasino is a similarly excellent example.

[dooglus]

The argument I'd make is that this longer process allows for real time verification, which I find preferable.

We used to allow players to 'randomize' any time they wanted to, but we had one player who did it after every roll. This was causing us to have to store huge numbers of pairs of seeds in the database.

I thought it was an attempt at some kind of denial of service, and so just put a limit on it - "you can only randomize after you've used a seed-pair 10 times".

But now it has dawned on me - it was you, with an automated roll verifier!

Am I right?

After a while of fighting against DDoS attacks, everything starts to look like an attack, even innocent things.

[Namworld]

This explains it then... now I know why I have more statistically accurate rolls on just-dice and coinroll than I do on other sites.
To bad Prime has the best sig rate, or else I'd be promoting CR or JD

I doubt Prime cheats at all. Coinroll might start advertising again soon, depends on what the new owners want to do.

----
@cwil

I agree if there's an automated system that changes client seed reliably. I'm saying it's convoluted for those that don't because they'll say all their bets are provably fair, they'll show how to verify bets, etc, with no mention that it's the case only if the user changes his client seed. It's simply not accurate if they don't have a system in place that make sure client seed is provided after server seed.

[cwil]

The argument I'd make is that this longer process allows for real time verification, which I find preferable.

We used to allow players to 'randomize' any time they wanted to, but we had one player who did it after every roll. This was causing us to have to store huge numbers of pairs of seeds in the database.

I thought it was an attempt at some kind of denial of service, and so just put a limit on it - "you can only randomize after you've used a seed-pair 10 times".

But now it has dawned on me - it was you, with an automated roll verifier!

Am I right?

After a while of fighting against DDoS attacks, everything starts to look like an attack, even innocent things.

That seems likely

Edit: There was a name change bot and some complaints about the lack of UTF-8 characters at some point too, though it seems UTF-8 support was eventually implemented.

[dooglus]

It was still provably fair, and I could in fact arbitrarily change my nonce

What's that? This is news to me.

Do you mean by making 0 BTC bets to increment the nonce?

Or something cleverer I don't know about?

[cwil]

It was still provably fair, and I could in fact arbitrarily change my nonce

What's that? This is news to me.

Do you mean by making 0 BTC bets to increment the nonce?

Or something cleverer I don't know about?

Nope, I could just change the nonce to whatever.  Search your DB for any bets with a negative nonce, I bet you'll find a couple.

[001sonkit]

actually there are two problems in this field
1: mentioned by Namworld
 (I wonder if some would even cheat on user by grabbing the client seed and change the server seed if the server seed is not requested by the user)
2: Too many people PR on their Provable results to provably fair


PhonyDice should be a better name for PD....

Shameless ad:I'd better stay in Dicenow and leverage invest the house to riches

[dooglus]

Nope, I could just change the nonce to whatever.  Search your DB for any bets with a negative nonce, I bet you'll find a couple.

That sounds dangerous.

Couldn't you set it back to 1 and re-roll the same numbers you've already seen?

It's going to take a long time to query the DB since there's no index on the nonce column.  I'll let you know the results.

[cwil]

Nope, I could just change the nonce to whatever.  Search your DB for any bets with a negative nonce, I bet you'll find a couple.

That sounds dangerous.

Couldn't you set it back to 1 and re-roll the same numbers you've already seen?

It's going to take a long time to query the DB since there's no index on the nonce column.  I'll let you know the results.

Well, I did tell you after months of trying, I was never able to find an exploit in your game.  It would not let you bet with an already used nonce.  This was pre 145,000,000 bets if I remember correctly, that may help.

[dooglus]

Nope, I could just change the nonce to whatever.  Search your DB for any bets with a negative nonce, I bet you'll find a couple.

That sounds dangerous.

Couldn't you set it back to 1 and re-roll the same numbers you've already seen?

It's going to take a long time to query the DB since there's no index on the nonce column.  I'll let you know the results.

Well, I did tell you after months of trying, I was never able to find an exploit in your game.  It would not let you bet with an already used nonce.  This was pre 145,000,000 bets if I remember correctly, that may help.

The query finished:

mysql> select * from bets where nonce < 0;
Empty set (48 min 7.76 sec)

So I'm not sure what's going on. Are you thinking of a different site maybe?

Edit: there's code that sets the nonce to 0, and code that increments it atomically; there's nothing that sets it to any other value, so I can't see how it could ever go negative.