Fairness has always been a tough challenge for the Online Gambling Industry. When traditional casinos first stepped into the online world, the biggest challenge was to generate results based on random events. Unlike the real world, where one can use card shuffling or dice rolling to generate randomness, it was difficult to do the same with general random functions offered by various coding languages. The early attempt to solve this issue was the adoption of Random Number Generators (RNG) Algorithms by the casinos.
In RNG, results are generated based on a seed number (a random large number) that is unknown to the public. Seed Number is combined with an algorithm to produce a series of hashes that are unpredictable, non-repetitive, and uniformly distributed. These hashes are then used to determine the result of every bet. To make it more appealing to the players, casinos have their RNG algorithm audited by a neutral third-party auditor and display the ‘Certificate’ on their site.
With the RNG system, online gambling became much more popular and trustworthy to the public. However, it still has problems. The generation of results is still in the hands of Casinos. Players have no role in determining the result. They still have to rely on the casino and have to believe that Casino is following the RNG system fairly (which it may not be).
But with the revolution of Blockchain in the early years of this decade, online gambling has completely transformed! Blockchain opened new doors of innovation that were earlier unvisited by the coders. Hence, soon enough Casinos had come up with a new system of fairness, popularly known as the ‘Provably Fair System’. With the Provably Fair algorithm, players can participate in the process of result generation and don’t have to rely completely on casinos. Moreover, the player now has the authority to verify the result immediately after making a bet.
Unlike RNG where the source of generation of the result is a seed chosen by the casino, in the Provably Fair system, the seed is combined with the additional seed provided by the player popularly known as client seed or salt. So, the combination of the casino’s seed and client seed determines the result of the bet. To understand the system better, let’s take an example:
Seed Number – 845165 (in practice this number is very large)
Seed chosen by client – 524650
Algorithm used – SHA256
Under RNG system: SHA256 algorithm will be used to generate hash of 845165 (seed number) which will be b165e5e8fcbcf8d597cb5a29c0b311752554842fc838ee3e6c7dcccd9db343ca
Under Provably Fair system: Before generating hash, client seed is combined with the seed number, i.e.: ‘845165524650’ and SHA256 of this number will be b3113390d493525c4062847190d056c0822dd2ccae67b373ec9d3df4aeb88161
Do you see how the hash generated in the Probably Fair system is completely different from the one generated in the RNG system? In a Provably Fair system, casinos lose the sole discretion of generating results and the final result is always calculated using the player’s input too. Hence, casinos are no longer in the position to manipulate the results. This is the main reason why ‘Provably Fair Algorithm’ is considered the single most important development in the world of Online Gambling. In the next section let’s understand the process of result generation using the Provably Fair algorithm in detail, the technical working, and the common industry practices.
Before moving forward let’s first understand the popular terms used in the Provably Fair script in detail:
Ok! Since now we have a basic understanding of the various variables used in a provably fair script, time to have a complete understanding of the system by taking an in-practice real example:
So, the process starts with the casino choosing a server seed. In our case, let it be: 4d74402b863d0c8690a7bfdc58f1a2780cbaabde42f5eedda8fef9c2489c7eab. As we discussed earlier, it’s just a random input and can be anything. But casinos need to use a strong algorithm to generate server seeds so that they are highly random and players can’t anticipate them.
The next step involves communicating the server seed to the player. However, if the casino communicates a bare server seed to the player, the player can calculate the result beforehand and bet accordingly. So, the casino first encrypts the server seed and communicates the ‘hash of server seed’. The most popular encryption algorithm used is SHA-256. It is a one-way hashing algorithm and practically impossible to find the input from the hash. In our case, we will communicate, SHA-256 hash of the chosen server seed which will be 0bfb295705ae78632a3c7479adfc86178fa7c306791cdc5a1a64b92bf9b889b2.
Once a player receives the hash of the server seed, he will pick a client seed. In our example, let the client seed chosen by the player be: dwownvonqorodoacnvosvrt. Now the player will make the bets. Assuming that the player made 2 bets, he will then request the casino to disclose the server seed. After receiving the request, the casino will change the server seed and communicate the previous server seed in bare form.
Now the player has all the data to verify that the result is true, let’s see how:
Server Seed: 4d74402b863d0c8690a7bfdc58f1a2780cbaabde42f5eedda8fef9c2489c7eab
Server Seed (hashed): 0bfb295705ae78632a3c7479adfc86178fa7c306791cdc5a1a64b92bf9b889b2
Client Seed: dwownvonqorodoacnvosvrt
Nonce: 0 for first bet and 1 for second bet.
After receiving the bare server seed, the first step the player should follow is to check whether he received the correct server seed or not. For this, the player will match the SHA-256 of the bare server seed with the hash provided before the bet and make sure that the casino hasn’t changed the server seed after the bet. In other words,
SHA-256(bare server seed) = Server Seed (Hashed)
You can use this tool to calculate the SHA-256 easily: https://emn178.github.io/online-tools/sha256.html
The next step is to determine which hashing algorithm the casino uses to calculate the result. The most popular algorithm used by casinos nowadays is HMAC-SHA512 however, it can be any secure hashing algorithm. Let’s assume in our example that the casino is using HMAC-SHA512. HMAC-SHA512 algorithm requires two variables ‘key’ and ‘message’ as input and produces 512-bits output.
In our case,
Key = server seed
Message = client seed plus nonce
So for the first bet, we have:
Key = 4d74402b863d0c8690a7bfdc58f1a2780cbaabde42f5eedda8fef9c2489c7eab
Message = dwownvonqorodoacnvosvrt0
There are various tools present online to calculate the HMAC-SHA512 hash, here’s the one you can use: https://www.freeformatter.com/hmac-generator.html
The resulting hash will be: 1e8734d7837322dec5e5d269205fdb469cf4697288cc14bc5971129ee6563636c5a820eeb92326a2a7606cb027a8df884de1fc313b512fc54ae8d491489299f9
More about how this hash is used to calculate the result of various games in the next section.
In single-player games, casinos generate different server seeds for each player and communicate the hash of the server seed to the player. The Player then has sole discretion in choosing whatever client seed he wants. The process is similar to what was discussed in the last section. Now let’s take that example forward and see how the hash that we generated can be used to determine the result in the ‘Dice’ game.
HMAC-SHA512 hash = 1e8734d7837322dec5e5d269205fdb469cf4697288cc14bc5971129ee6563636c5a820eeb92326a2a7606cb027a8df884de1fc313b512fc54ae8d491489299f9
Dice is one of the most popular online casino games. In dice, the player has to choose a range, for example, 0 to 50, and then a number between 0 and 100 is rolled. If the rolled number is between the player’s range, the player wins, else he loses.
Since the hash generated by the HMAC-SHA512 algorithm is a hexadecimal number, it can be converted into a decimal number easily. Decimal means 10 so decimal numbers are nothing but normal 0 to 9 we use in daily life. Whereas hexadecimal means 16 so hexadecimal number starts with 0 to 9 and then 6 additional characters i.e. ‘a’ to ‘f’. So, 15 in decimals equals to ‘f’ in hexadecimal.
For the dice game, we evaluate a hash in the chunk of 5 characters at once. The value of 5 characters in hexadecimal can be between ‘00000’ to ‘fffff’. As a convention, 0x is used in front of hexadecimal so we can say 5-characters hexadecimal numbers can have values in the range of 0x00000 – 0xFFFFF. The decimal equivalent of 0x00000 is 0 whereas 0xFFFFF is 1048575.
Now in our case, the first five characters of the hash are 1e873 or 0x1E873. Since this is a hexadecimal number, we have to convert it into decimals. The decimal equivalent of 0x1E873 is 125,043. As we discussed earlier, the value can be between 0 and 1,048,575. So, it may be possible that the value of the first 5 hexadecimal characters is above 1,000,000. In such a case, we will ignore the first five characters and take the next 5 characters. The process will continue until we get a value lower than 1,000,000. Since in our case, the value is 125,043 which is lower than 1,000,000, it is a valid case and we don’t have to move to the next 5 characters.
Now we have to take the modulo of 125043 with respect to 10000. Modulo is nothing but the remainder after dividing a number with another number. 125043 when divided by 10000 leaves 5043 remainders. Hence 125043 mod 1000 equals 5043.
The final step is to divide the remainder by 100. In our case, 5043/100 equals 50.43.
Hence, 50.43 will be chosen as the roll of the dice. If the player has selected the range of 0 to 50, he will lose the bet because the roll number is higher than his range.
In multiplayer games, casinos provide the same server seed for each round to all the players. Now the question arises: what would be the client seed since more than one player is playing the same game? To solve the problem, casinos pick an event as a client seed over which both casino and players have no control. Such an event can be a hash of the Bitcoin or Ethereum block. The next question arises since everyone knows that the block hash will be used as the client seed, isn’t it possible for the casino to pick a server seed that when combined and hashed with the block hash produces results in favor of the casino?
To solve this issue, the casino commits all the server seeds which will be used in the future before the block is mined. Suppose the casino is planning to use the hash of block number #647000 as a client seed that has not been mined yet. Then the casino will generate let’s say, 10 million server seeds and provide the hash of all server seeds in the public domain before block #647000 is mined. In this way, casinos will have no control over the future results because they have no knowledge about client seeds while generating the server seeds.
However, another question arises: isn’t it cumbersome to provide 10 million hashes in the public domain? How will players verify data that huge and make sure that every seed is used in sequence? To solve this problem, the concept of ‘hash chain’ is used. As we read in the previous sections that it is practically impossible to find the input from the SHA-256 hash. So, using the benefit of this algorithm, casino will pick a starting seed, let say: a558d24559fe35e7e8feadb080b92b339e2c42ce1808a96dfa4eb4045ce2c63f
Now it will generate the SHA-256 hash of the starting seed. Further, the casino will generate the SHA-256 hash of the hash of the starting seed and this process goes on 10 million times.
Finally, we will have 10 million hashes but each hash is the SHA-256 hash of the previous hash. So instead of providing 10 million hashes in the public domain, casinos will just provide a single hash i.e. 10 millionth hash in the public domain before block #647000 is mined. Now the casino will use 9,999,999th hash as the server seed for the first round. After the round is over, it will provide the 9,999,999th hash to the public. Now the public can verify that the SHA-256 of the 9,999,999th hash is equal to the 10,000,000th hash. This process will continue and the 9,999,998th hash will be used as the server seed in the second round which will be provided to the player after the round and players can match its SHA-256 hash with the 9,999,999th hash and so on.
Coming to the crash game, the player puts a bet before the rocket starts. Then he has to withdraw the money before the rocket crashes. For example, the player puts the bet of 0.01 BTC and the rocket starts, he clicks the withdrawal button at 2.00x and the rocket doesn’t crash prior to that then he will be paid 0.01*2 = 0.02 BTC. However, if a rocket crashes at let’s say, 1.61x multiplier then he will lose the bet of 0.01 BTC.
To determine the result of a crash, casinos can use any algorithm; however, HMAC-SHA512 is the most popularly used. Let’s take an example,
Server Seed (also known as game hash) = 23f189fac071edfe0c2428ef151852efa9396d76f2447c8a1d80b3799d511eae
Client Seed (also known as salt) = 0000000000000000000d81f8d41b31fa1fe08c1a3b723f32f656a2df52640b26
As we discussed earlier, the HMAC-SHA512 algorithm requires two inputs ‘key’ and ‘message’, in this case, casinos can use any of the two as a message, however, a game hash is mostly used as a message and salt as a key.
So HMAC-SHA512(gamehash,salt) = 4decd400c652bb7912622b3f74f15f81895203728fbe615a8ffc8c5433df5bd2de18a4b103384f896e45fa2cfbd34fbea4ace2fcf137fec9d1c47550d1b9645b
Then the first 13 characters of the hash are taken into consideration which in our case is 4decd400c652b or 0x4DECD400C320B (since hexadecimal). Now we have to convert it into a decimal form which will be 1370873031058731.
Finally, a special formula is used. Different casinos have different formulas but the following is the most popular and was developed by the Bustadice owner:
Multiplier = 99 / (1 – X)
where X = number / 2^52
In our case, number = 1370873031058731, so the multiplier will be:
M = 99 / [1 – (1370873031058731/2^52)]
M = 1.42
Hence, the rocket will crash at a 1.42x multiplier.
We hope the concept of Provably Fairness became much clearer to you after reading this guide. However, as we discussed earlier, different casinos follow different provably fair implementations. Some use HMAC-SHA512 while some use SHA-512 hashing algorithm, some increment nonce from 0 while some increment nonce from 1, their crash game algorithms can be different too. So, the process we discussed may not be true for every casino. To solve this problem, we have developed an in-house provably fair verifier and currently supporting over 25 casinos. You can use this tool to verify your bets and the result will automatically be optimized depending upon the selected casino’s implementation: https://www.btcgosu.com/tools/provably-fair-verifier/.