ProvablyFair.world
GUIDES

An introduction to provably fair games

”Provably fair games” are games allowing the players to get a mathematical (and irrefutable) proof of their fairness.

Generally speaking, such a game lets the players verify by themselves that the draws are random, that the game’s data are not modified after the betting round, and/or that all goes according to known rules or parameters (house edge, odds, etc.). Simply put, a provably fair game is a game behaving exactly as it should, and being able to prove it without any doubt.

Provably fair games rely extensively on cryptographic hashes. A hash is a one-way transformation of any text input, resulting in a series of characters that cannot be deciphered (if you are not familiar with this, you should definitely read our guide on hashing first).

Different methods, different levels of fairness

Most provably fair games work according to the same principles: the operator generates some random numbers, conceals them in hashes, and makes these hashes public (by showing them to the player or recording them on a blockchain, for instance). When the game is over, the player will be able, given the game outcome, to verify that everything ran as it was supposed to.

But this process can be more or less complex, sophisticated, and fair. To simplify, and without talking about decentralized apps (that are based on slightly different principles and technologies), you will meet two different kinds of provably fair games: some that simply give the proof that the draws are not altered after the betting round, and others that do that but also allow the players to influence the outcome and its randomness.

Therefore, you will meet these two common methods:

Method 1:  giving away the hash
The operator produces some random numbers (seed) used in his game to form a specific combination for a draw, roll of dices or lottery. Then he calculates the hash of this combination, and provides this hash to the player, before any betting.
After the game, the player has the possibility to easily verify that the combination was not altered after his betting. He will simply take the combination, hash it and compare it to the hash he/she was given at the beginning.
This method is good and offers a first level of fairness, but it’s not enough.

Method 2: adding a grain of salt to the outcome
In this case, not only is the operator providing a hash of his random numbers, but the players can also pick some random numbers that will be used to produce the final combination. In the jargon, the player will provide his/her own ”seed”, or add ”salt” to the outcome, resulting in a more random and more fair game.
This solution is much better and should be the norm for most truly provably fair games.

An imaginary example: a provably fair shuffled deck of cards

In order to illustrate, let’s detail these two methods in a simple case.

Take a standard deck of 52 cards. Shuffle it in a random way, like an actual live dealer would do. Now write a list of the cards in the exact order in which they appear after your shuffle:

10s Kh 2d As 8c Qd... (c for clubs, d for diamond, h for heart, s for spade)

Apply a hashing function (like SHA-256) to your list. It will become something like:

fe17e0d8f50f496bb6be92b0a366e0aa8f5469b896d5d78c9532de077e0c52a1

You now have a string of characters that uniquely identify your deck of cards. Only the exact order of cards in this deck can produce this hash.

In case you wonder, a deck of 52 cards can be combined in 8.01 x 1067 ways. That’s a 67-digit number! Quite huge. And that’s the number of possible hashes you would get if you wanted to hash all possible 52-cards deals. Looking at a hash and knowing it represents a list of cards, there is absolutely no way anyone can ”read” or ”guess” the order of the cards.

Now imagine a standard Texas Hold’em online poker game, with ten players seated at the table. Before the game (and the betting round) starts, the operator can publicly display the hash of the deck that is going to be used.

After the game is played and everything is over, the operator can give the list of the original shuffle in a humanly readable form. Anybody can then verify that this list was the only one that could lead to the given hash. Therefore, all players can be sure that the deal was not modified during the game. For instance after a player went all-in on the flop, there is no way the operator could have changed the last card appearing on the river to make he/she lose.

This is good (and fair): we are now 100% sure that the operator cannot modify the outcome by interchanging cards during a game. But we are not sure of anything else – and that’s a problem.

We don’t know for sure that the original shuffle was purely random. For instance, since the operator knows that there are 10 players at the table, he could arrange the deck so that, ”very often”, when a player is dealt AA, someone else gets KK. Or so that, when someone is given 33, there is ”very often” another 3 on the river. Knowing the initial hash of the deck would not change the fact that the game is rigged.

To make the game ”more provably fair”, we can allow the players to add randomness to the process. This is quite simple, and we can proceed as we would in a live game, by allowing people to cut the shuffled deck:

  • The operator shuffles the deck and publishes its hash.
  • A randomly chosen player is asked to cut the virtual deck, by choosing a number between 1 and 52. This number is public and all players can see it. If he/she choses 17 for instance, the first 17 cards from the original deck will go at the bottom of the deck, and the 18th card will become the first card of the new deck.
  • The cards are dealt and the game is played.
  • At the end, the operator can reveal the original deck (before the cut) and the deck actually used for this game (after the cut). Everybody can verify that the cut was properly taken into account.

In this case, it would be nearly impossible for the operator to fix the outcome, since he cannot predict where the player will cut the deck. The player has added ”salt” to the randomness: not only is the shuffle more random, but the player directly influenced the outcome, without knowing in which way.

Real world example : provably fair online slots

The same mechanisms can be applied to pretty much all kinds of games. For instance, the mechanism used for provably fair slots games is the following (this is the process actually used by BetChain, but most operators use similar processes):

  • Using a Random Number Generator (RNG), the next spin of reels is generated. This random number is called ”Result” and mathematically describes the position of the reels on a virtual slot machine.
  • Another random number called ”Secret” is produced.
  • A unique signature (or ”Fingerprint”) is produced by hashing the 2 previous numbers. Fingerprint = hash (Result + Secret).
  • Fingerprint and Secret are provided by the operator to the player, before the game starts. Since it’s a cryptographic hash, the player cannot decipher this signature and therefore cannot guess the next position of the reels on the slots.
  • The player can add a grain of salt, by choosing an additional number of spins for each reel. This number is ”Salt”.
  • The player places his/her bet. The game is played, the reels spin and stop.
  • Finally, all the data is revealed: the player can see ”Result” and ”Secret”. He/she can hash them and compare the actual result to the initial Fingerprint. And he/she can confirm that the chosen additional spins (Salt) were added to Result before the reels actually stopped.

Since all the numbers match, the game was provably fair.

Share through: