Topic: Breaking: Shuffle-based Provably Fair Implementations Can Cheat Players (proof) - page 4. (Read 4659 times)

So, maybe I'm not reading it correctly, but the idea is not to produce a deck that wins every single time, if that's what you meant by "100% success." Rather, to produce a deck that causes the player to lose more than the expected average. In other words, you're not looking to have a dealer 20 every time, just perhaps more often.

Imagine we're playing 6-deck blackjack described at the Wizard of Odds. For each hand, the net summarized win is as follows: player wins 42.42% of the time, pushes 8.48% of the time, and loses 49.09% of the time. What shufflepuff can do is create decks that incrementally perform like this:

Average: win 42.42%; push 8.48%; loss 49.09%
Iteration n: win 41.20%; push 8.50%; loss 50.3%
Iteration n + p: win 40.85%; push 8.62%; loss 50.53%
Iteration n + p + q: win 39.10%; push 8.75%; loss 52.15%

When you use iteration n + p + q, there will be seeds where the dealer loses (player wins), but the player will lose more often than before (on average). So, using this arrangement, the casino can permanently alter the house edge.

Yes, so that's part of the heuristic I mentioned earlier. There are games, such as roulette, which require play history. However, there are others, such as blackjack, that are exclusive. The exploit works regardless. In addition, you don't really need to account for 'strange' plays, as the goal is to reduce favorable cards for the player, or encourage favorable cards for the dealer. Since the dealer doesn't play strangely, the exploit works. Here's a brief overview:

Roulette

• Optimizations: favor one color over another; favor thirds; favor number; reduce instance of number, color, or third.
• Heuristic: Brute-force. The arrangement space is computationally feasible.
• Deployment: Requires at least one game played to stack decks.

Blackjack

• Optimizations: player receives bust hand (13-16); deny player ace; house starts with 10, Ace, or non-bust card; reduce splitting; reduce doubling; reduce dealer busts, and more
• Heuristic: Create translation decks using the seed space. Since most blackjack games average 6-7 cards total dealt, attempt to optimize by best-fit.
• Deployment: Mutually-exclusive. Exploit works regardless of prior play.

For blackjack, you're not necessarily attempting to combat random play (random hits, random doubles), but rather, encourage favorable cards to the dealer and encourage bad cards for the player. So, you're looking for arrangements that give the dealer an Ace more often than not, give the player a 6, reduce the likelihood of splitting, doubling, and so on. Beyond that, you'd want to allow for the house to make their hand (try to keep a slug of low cards beyond the 7th position of the final deck, etc.). You can also optimize to combat basic strategy and 'upgrade' the cold decks when prior play history suggests the player is playing this way.

Blackjack works due to the extremely large arrangement space. You're talking 416! / 128! / (32!)⁹ possible arrangements in an 8-deck game. Since your target is only 2³², that means you need to find an arrangement that works well against the 2³² / (416! / 128! / (32!)⁹) shuffles in the final space. The number is so small that most calculators can't even represent it. It's possible there exists an arrangement that beats all possible seeds.


Video Poker

• Optimizations: encourage dead hands for the first 10 cards; reduce royal flush, straight flush, and so on; allow for good primary hands (like four to a straight flush), but deny matching card, and more
• Heuristic: Create translation decks using the seed space. Reduce translations to first 10 cards and attempt a best-fit optimization.
• Deployment: Mutually-exclusive. Exploit works regardless of prior play.

This is just a partial list. I'll elaborate more when I publish the optimized decks. This is pretty much where I started when I attacked the problem.

Addendum: Also, remember, the goal of shufflepuff is to not discover the uber-optimized deck, just ones that perform better than others. So, a casino operator performing a random search would probably do well in the short term with shufflepuff vs. hiring a mathematician to construct a heuristic.

I think that would be extremely valuable... also, how would a 'rigged casino' account for games that have unexpected customer behaviors? Like hitting or staying in Blackjack, or going randomly red / black in roulette?

Not discounting what you're saying technically, but I just don't see how a rigged casino could account for these variables.

Thanks for the feedback!

I thought about doing a video, but didn't really know if it would cultivate interest. I'll rethink the idea. Might be nice seeing the exploit visually.

The last line of your (trevor) post hit me big. From the start, I don't really like playing shuffle-based games (like baccarat, card games or the likes), as I thought that they can be somewhat rigged. Well, turns out that I'm right on my thoughts after all, but with that I'd like to see a video demo of the exploit as "provably fair" casinos seemed to not be fair at all.

I'm intentionally waiting on this for a bit until players become aware of the exploit. If I were to drop the optimized decks right now, they could immediately be used to cheat players.

You can generate your own non-reference decks using the code I provided. Simply let it run. On a single-core machine, it takes less than a day to scroll through an arrangement. A few tweaks and you can go multithreaded and cut the time down significantly. For reference decks, you'll have to rewrite parts of it to conform to the target casino.

In roulette, for example, you will receive a deck arrangement and a number. The number corresponds to how many seeds were beaten. If the number exceeds the expected probability of the draw, then it is a partially-optimized deck.

I fully agree with you that a player needs to know if any exploit exists and decide himself to play at those casinos or not

thx again for your very interesting findings

I'd love to see some working examples of a 'rigged deck' in blackjack, baccarat, roulette, whatever - where the client seed has no effect on the end shuffle using Provably Fair Shuffle.

You're welcome! It's natural for any cryptographic mechanism to show weaknesses over time. They (almost never) get stronger. Eventually, they are replaced with modern versions, which I think will happen here as well.

If I were a card player, I would rather know that an exploit exists than not know and be silently cheated out of my coins.

thx for confirming it but to be frank I am not happy about your findings because players could stay away from those popular card games

You're right, JackpotRacer, the exploit works regardless of client seed. You could change the client seed every time with random data; the house will still win more often than expected if it uses an optimized deck.

Kinda like Crypto-Games.net does?

did I miss the point the OP did or you? I understood that OP said that even you change the client seed the casino has an advantage (if they want) in card games like BJ or Baccarat

Agreed Stunna... All players should change the client-seed when offered, and not trust the casino's version of it; regardless if they've been around forever (like Bitzino or PrimeDice), or been around since 2013 (Us).

Can you give us a list of casinos that use bitzeno?
I think it would be helpful

Thankd

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)

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.

Thank you!

It's more than that. I'm claiming that the shuffle-based games are actually not provably fair. This is a direct attack against the algorithm.

Here's why:

• On a mid-range CPU (like a Core i5), a casino can calculate a single arrangement in about 17 hours.
• Since it is not looking for the "ultimate" arrangement (just a better one), it can continuously search one arrangement at a time and update its "master list" of cold decks that result in a higher house edge.
• These deck arrangements, over time, will always perform better.

I have written a new implementation that I will share here soon. I won't go so far as to say that it is "perfect" (since there is no perfect crypto), but maybe "next generation"?

I don't think that's a great idea. You're better off by creating a random number stream like this:



(i.e. something along the lines of how dice sites currently generate outcomes.) The modulo-bias is so insigificant, that you could run it for a billion years and not hit a case of it. Anyway, instead of assigning a random number to each card and sorting you're better off sticking with a Fisher–Yates shuffle, which is proven to be perfect with no bias. (Which is a fancy way of saying, you loop through the deck of cards and for each card you generate a random index. Then you SWAP the current card, with the one at that index. And continue on your loop. Once you get to the end of the loop, you're guaranteed to have perfectly shuffled it.

The psuedo code from wikipedia: