Great point! I have to say, I think this is one of the best responses I've seen to an operator rebuttal.

I didn't think it would happen, but after sending some e-mails off to a couple casino operators, I received similar public relation / marketing responses. Discussed some of the importance here.

A few years ago, I posted some side-channel attacks on provably fair. Received, pretty much, the same response.

A total guess, but somewhat similar to the Vegas Strip changing their 3:2 blackjack to 6:5. In this case, casinos realized that the demographic of the Strip that didn't care about odds outweighed the others. Those who did care were more likely to move off-strip anyway in search of better odds, basically becoming the niche market.

Perhaps the frontier of provably fair will only move so far as players demand it. Rather, I hope casino operators take a proactive approach.

I looked at BetKing's provably fair implementation and determined that they can use shufflepuff as an exploit AND their shuffle algorithm has a modulo bias. In general, for an eight deck blackjack game, the modulo bias occurs once every 200,000-400,000 hands. Not a lot, but easily fixable. To fix the modulo bias, BetKing would want to discard any number n where n >= MAX - MAX % modulus, where MAX = 2³² - 1.

A good thing about BetKing is that they keep their code simple and easy to read. This is in contrast to some casinos that have very complicated methods for similar functions.

Thank you for writing, Angelina Jolie!

I'd love to, but I try not to comment on specific casinos unless I've taken a fairly deep look into how they operate. This takes a considerable amount of time. Hopefully, there are some sources where others have taken a look at these websites? Are the ones you're referring to on-chain betting?

I can make some general comments about shuffle-based provably fair systems, in case you encounter them. I know it may not be helpful for the specific casinos you're referring to, but you never know.

When I looked into the shuffle-based provably fair systems, many of them suffered from the following:

• Sole control over the initial arrangement of the cards. This is the basis of shufflepuff, which I believe "breaks" the provable aspect of "provably fair" for many of these casinos. Adapting shufflepuff to their provably fair method would allow a casino to take advantage of you.
• Modulo bias in the shuffling algorithm. This is normally not a big deal for most applications but a considerable gaffe for a casino (which markets fairness). It shouldn't exist, really. In general, depending on where the Fisher-Yates algorithm starts shuffling (the beginning or the end of the deck), a casino can favor cards in certain spots. Though rare, sophisticated usage of it can result in the player being denied a card (like an Ace in blackjack) or given a card (like a 5 or 6).

If you have any other questions, let me know!

I can't render an opinion on Pocketdice, but it looks like NLNico and RHavar have seen obvious defects which would preclude it from being provably fair.



The way I see it, "provably fair" (the concept) is marketed by casino operators with several claims. Here's a sample (emphasis added in bold):







When presented with a viable weakness, however, casino operators seem to resort to a promise (which requires trust) or marketing (emphasis commentary added in bold):





From my perspective, if the provably fair system isn't "provable" then it can only degenerate into a simple promise of fairness. A promise requires that you trust the casino, which is contradictory to the casino's claims.

Many of these casinos have been around for some time, so they tend to be a little dismissive when an attack is presented. It's natural: they have established a base of players, some of whom might play regardless of provable fairness, some who don't verify anymore, some who may amplify claims, and so on. And they've likely received more than their fair share of claims from players about cheating.

Truly interesting responses. Thanks for the question, DarkStar_!

You bring up a good point.

When I first published the side-channel attacks a couple years ago, some casino operators dismissed it by saying things like, "We would never cheat," or "if we did this, we'd get caught" or "if we were caught, we'd lose all our players," without addressing their implementations of provably fair. So, they are countering a cryptanalysis with a PR/marketing spin, which doesn't make sense.

By saying, "We would never cheat," without addressing their implementation, they are only offering a simple promise of fairness, which is no different than a non-provably fair casino.

You may have read it incorrectly. This is a direct attack against most shuffle-based provably fair implementations.

While it may take time to evaluate a single arrangement, once the arrangement is found, the house can generate an enormous number of stacked decks. These are trivial to create, and can permanently sway the odds of the game despite an advertised house edge.

That's a great question. This is a common issue among crypto-developers. You may have heard the mantra from developers, "Write it, even if it breaks." Unfortunately, crypto-developers aren't afforded the luxury. If crypto is implemented and breaks, it can cause direct harm. Total losses, breached accounts, really bad stuff. Look at Meteor. They had SRP implemented but reverted back to bcrypt because maintaining the crypto code required far more resources that were best used elsewhere.

In a nutshell, I had penned an implementation a couple of years ago, had it in peer review but it quickly became cost prohibitive.

Granted, I can't speak for an organization that is interested in the research. It may end up being a benefit to all. Some time and resources to fully publish, maintain, and be there to actively improve the work.

I have a fair method for investors – will publish in due time – but currently in talks with another group that wants to license it to be first-to-market.

Either way, it appears likely to be open-sourced.

Just checking in with you, casinobitco, if RHavar provided enough information for you to examine shufflepuff in greater detail.


A Provably Unfair Blueprint

Here's what a malicious casino would do if they wanted to cheat.

#1: Take your standard roulette wheel and letter encoding.

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35	36
0	1	2	3	4	5	6	7	8	9	a	b	c	d	e	f	g	h	i	j	k	l	m	n	o	p	q	r	s	t	u	v	w	x	y	z	A

#2: Convert the wheel to a point deck based on the desired optimization.

Here, we represent the wheel as a set of points. For illustration, we'll keep it simple and use a zero (0) as neutral and a one (1) for the wheel positions that favor the house. You could use weighted values, like -1 and 1 to show the exact deviation in favor of the house or player. I prefer 0s and 1s to stay aware of the count within a space (just a math thing).

Examples:

Optimize for Color (red/black)
0 000000 000000 000000 111111 111111 111111

Optimize for Green
1 000000 000000 000000 000000 000000 000000

Optimize for Third
0 111111 111111 000000 000000 000000 000000

For this example, I'll choose to optimize for color.

#3: Run shufflepuff with the desired seed space.

First, let's compare the seed space (2³² = 4,294,967,296) and the arrangement space (37! / 19! / 18! = 17,672,631,900). The seed space covers about 24.3% of the arrangement space (4,294,967,296 / 17,672,631,900). What does this mean? It means that there are some final shuffles that are unattainable if the house decides to optimize the deck. In roulette, we're drawing one "card" (number). To optimize, we want to push as many favorable shuffles for the house into the seed space, and push as many favorable shuffles for the player outside of the seed space (into the unattainable space). This seed space covers a relatively "large" portion of the arrangement space, so one would expect there to be optimization, but smaller optimization than in other games, such as blackjack.

Someone might say, "Wait, there are actually 37! possible initial decks in roulette." That's true, but since we're optimizing for color, we can cut down our search space by ignoring the order of the numbers and focus on the position of the colors. You'll see why in a bit.

As a toy example, let's reduce the seed space to something small, like 40. Fire up shufflepuff and you'll see this:

0000000000000000000111111111111111111: 16
0000000000000000001101111111111111111: 17
0000000000000000001111011111111111111: 18
0000000000000001000111011111111111111: 19
0000000000000001001101011111111111111: 20
0000000000000001001111011101111111111: 21
0000000000001001001101011101111111111: 22
0000000000001001001111011100111111111: 23
0000000000011001001111011100110111111: 24
0000000000111001001111011100110011111: 25
0000000001001001001101011100111111111: 26
0000000001001001001111011100110111111: 27
0000000001011001001111011100110011111: 28
0000000001111001001111011100110001111: 29
0000000011111001001111011100110001110: 30
...
0000111001001001001111011100110001110: 35

The last line indicates the arrangement and the number of seeds (out of 40) that are beaten. So, in this example, if we optimize for the house, the house will win 35/40, or 87.5% of the time.


#4: Partition the roulette encoding scheme and randomize.

For this instance, I'll optimize for black, meaning I want black to appear 87.5% of the time. So, I'll partition the encoding into red + green, and black:

Red + Green: "013579cegijlnpruwyA"
Black: "2468abdfhkmoqstvxz"

Now we randomize each encoding:

Red + Green: "Awp1yejr5c3ngi07u9l"
Black: "davhk4mtz82sbof6qx"


#5: Zip the shuffled encoding onto the optimized arrangement.

0000111001001001001111011100110001110 =
Awp1     ye  jr   5c  3n       g      i0     7u9      l
        dav   h   k    4   mtz8  2sb    of       6qx

Result: Awp1davyehjrk5c43nmtz8g2sbi0of7u96qxl

You can keep randomizing to create 19! * 18! = 7.788 x 10³² cold decks. Using this deck, or any under this optimization, results in black appearing 87.5% of the time, despite an expectation of 18/37 = 48.65%. There is no way for the client to randomize their seed enough to beat this optimization.

Granted, with a 2³² seed space, you're not going to get such a dramatic result. Additionally, even if you found a high optimization, you probably wouldn't play it often (tuck it away as your "nuclear" option).

Here's the big thing: You also have all the arrangements > 20 that also work well. They can also be randomized and used against the player. Again, the casino doesn't necessarily want to find the best deck, just a better deck.

It's also easy to optimize for red now. Just flip the red and black (leave green alone).


Let me know if you have more questions. Thanks for reading!

Addendum
Remember, the shufflepuff code does not adhere perfectly to any one particular casino, so while it will give you optimized decks for its configuration, the decks will fail if implemented. This is intentional.

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.

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.

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.

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.

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.

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"?

Good catch, but sadly, the seed maxes out at 2³² – 1.

bitZino combines the server seed and client seed, hashes it with SHA256, but then only uses the first 8 bytes of it. So, the range is 0x0 to 0xFFFFFFFF. (FFFFFFFF)₁₆ = (4294967295)₁₀. They write about this in their techblog: https://techblog.bitzino.com/2012-06-30-provably-fair-shuffling-through-cryptography.html

Thanks!

Edit: Thought about it some more... The answer is 'not exactly' (see new reply).

Totally right. You bring up another really good point. Using shufflepuff, we can feed it a truly fair roulette wheel (36 cards) playing red or black and still optimize the initial deck in a way that favors the house.

After a few minutes:

000000000000000000111111111111111111: 2496
000000000000000001111111111110111111: 2500
000000000000000010011111111111111111: 2526
000000000000000010111111011111111111: 2533
000000000000000010111111110111111111: 2538
000000000000000010111111111110111111: 2545
000000000000000011111111111110011111: 2546
000000000000000110111111110110111111: 2549
000000000000000110111111111110011111: 2553
000000000000001010111111011110111111: 2560
000000000000001010111111110110111111: 2565
000000000000001010111111111110011111: 2569
000000000000001110111111110110011111: 2573
000000000000010110111111110110011111: 2577
000000000000011010011111111110011111: 2581
000000000000011010111111010110111111: 2584
000000000000011010111111011110011111: 2588
000000000000011010111111110110011111: 2593

Anything above 2500 actually favors the house, despite the cards being in a "fair" distribution (18 red, 18 black).

Granted, advertising a 0% game would be silly and raise red flags, but an ultra-low edge would work well.