Understanding Provable Fairness: Seeds, Hashes, HMAC and mathMAX

When it comes to gambling, trust is everything. Without a sense of fairness, the excitement just isn’t the same.

In our previous brush with this topic, we’ve touched on crash gambling algorithms and gave a quick overview of provably fair RNG algorithms. But by popular demand, we’re here to dive deep into how provably fair systems really work.

If you’re curious about why you can trust provably fair casino games, you’re in the right place.

---

🔑 Key takeaways:

• Provable fairness is a concept in online gambling that ensures fair and transparent game results. Cryptographic principles are used to achieve this.
  
• The formulas used in crash games, such as Stake’s Crash, involve various parameters like server-side seed value, player seed value, and house edge. These parameters determine the final result, which determines the player’s payout.
  
• The final calculation in the provably fair process ensures fairness by converting the game’s combined hexadecimal hash into decimal numbers, adjusting for the house edge through a proprietary formula.

---

Understanding Provable Fairness

Before we discuss the cryptographic principles behind every provably fair algorithm, let’s cover the basics first. Here’s a short explanation of the technology that makes crash gambling legit.

What is Provable Fairness?

Provable fairness is a concept implemented in online gambling games like crash to ensure that the results generated by the game are fair and transparent. This is done by using cryptographic hashing principles.

Provably fair casino games allow the players to independently verify the outcome by using external cryptographic encryption tools.

By doing that, the player can verify that the game’s outcome was determined by a fair process and not manipulated by the casino or any other external party. This transparency builds trust between the players and the gambling platforms while also providing a secure gambling environment.

Cryptographic Principles Behind Provable Fairness

At the core of provable fairness, the application of cryptographic principles ensures the transparency of the game’s outcomes. To understand cryptographic principles, we need to cover three key concepts:

• Hashing functions
• Data integrity
• Pre-generated randomness

Hashing Functions

Hashing functions are essentially tools that take an input or a message to produce a fixed-size string of bytes, known as a hash value (or digest). The key thing to understand here is that each message or input always generates the same output.

This “deterministic nature” of hashing, as it’s commonly called, is what makes provable fairness work consistently and predictably.

Data Integrity Pre-Generated Randomness

The whole idea behind provable fairness is that neither casinos nor game providers can tamper with game results.

To ensure the process of provable fairness can be trusted, the seed value or outcome that the casino or game provider generates is hashed and sent to the players before the round begins. This hash then serves as the key to the integrity of the process.

If the casino tampered with this seed value, the game’s outcome would result in a different hash value, meaning the game had been tempered.

The Process of Provable Fairness

Preparing for Fairness

I called this the first stage of the fairness process, “Preparing for fairness.” Here’s everything that happens in this stage:

1. The casino or game provider generates a random server-side seed value.
   As mentioned before, this value remains undisclosed until the game concludes and serves as the key element determining the game’s random outcome.
2. The user interacts with the game.
   When the player interacts with the game by placing a bet, the game generates a client—or player-side seed value. This seed value, in combination with the server-side seed value, generates a randomized game result.

Top-rated provably fair games allow the players to determine their own seed value, which can be anything!

Combining Seeds for Game Outcome

We’re already at the fun part of this process. With both the server and the player-side seed values in place, it’s time to mix them up! Here’s what happens at this stage.

1. Combining the seed values.
   As I just mentioned, with both the server and the player-side seed value in place, the algorithm behind the game combines and hashes the two to generate a random game result.
   
   Hashing the combined seed values provides a cryptographic fingerprint that you, the player, can use to verify the fairness of the game after it has ended.
2. The result of the game is determined.
   The hashed seed values are the basis for generating a randomized game result. The result is not dictated just by the casino; your seed value matters just as much. Remember, before you came along, the casino could not access or know your seed value.

Fairness Verification and Confirmation

The round of crash has ended at this stage, but the process isn’t done just yet. I’ll break this final stage of the fairness process into three sub-stages.

• The revelation stage: The casino reveals its secret seed to the player.
  After a round of the game ends, you can immediately access the server-side hash value, which serves as the basis for fairness verification.

• Player verification process: combining seeds and hashing.
  To verify the game’s fairness, you only need to verify that the combination of the revealed server seed and the client seed (or multiple seeds in the case of Aviator) matches the final combined hash.
• Importance of matching hash values in confirming fairness.
  If the hash you received back from an independent SHA256 or SHA512 encryption tool matched the one that was served to you after the game ended, you can rest assured that the game’s outcome was indeed random and fair.

I will use an independent SHA512 encryption tool to confirm the validity of the 3.77X outcome from the example above. Here is a step-by-step guide on independently checking fairness with data from Aviator by Spribe.

1. Google and find a SHA512 encryption tool.
   Any tool from the top of the search results will do.
2. Input the server and the client seeds with no spacing.
   Aviator by Spribe combines three client seeds with one server seed. The majority of crash games only combine one server and client seed value.
3. Click “Encrypt” or “Generate Hash”.
   The result should show instantly.
4. Check the hashed results and see if they match.
   The generated results should match the combined hash provided by the game. If they match, the game is fair.

The generated combined hash below matches the one from the ‘Combined SHA512 Hash’ section of the Aviator screenshot above. This means that the game was fair.

You can verify the execution of my process by clicking here.

From the combined hash, the game’s algorithm then takes the first 16 hexadecimal numbers, which are base-16 numbers (0-9 and A-F) and converts them to decimal base-10 numbers (0-9).

The game’s algorithm then uses the decimal numbers to generate the final result. This last step is where most games stop sharing information, but not all of them.

From Decimals to Result – The Final Step

Crash by Stake Originals is undoubtedly one of our favorite crash games. And a big part of that is the transparency behind the game.

To generate the server-side seed value, Stake uses a “gameHash”, which acts like a secret password for the game. They use the same ‘gameHash’ to create another secret code using a special technique called HMAC. Think of it like mixing ingredients to make a secret recipe.

Stake also use something called a “blockHash”, which is like a special code related to a future Bitcoin block. This adds even more randomness to the game.

By combining the ‘gameHash’ and the ‘blockHash’, they get a long string of numbers and letters. They then pick out just the first few characters to make a new number. This new number is then used as a server seed value, which dictates the game’s result after it is combined with the player’s seed value and hashed.

This is all transparently described in Stake’s public seeding events.

What is a public seeding event?

A public seeding event is a process in which a game provider publicly discloses the specific Bitcoin block they use as a source of randomness to generate random results for their games.

This disclosure is often accompanied by other relevant details, such as the timestamp, the formula used for calculating the end result, and the hash of the chosen block.

This is all done to provide transparency and allow players to independently verify the fairness of the game outcomes.

You can see an example of a seeding event in this Bitcointalk forum thread.

The screenshot below shows how Stake calculates the final outcome in their provably fair crash game.

Final Result Breakdown

The part of the formula above that we’ll focus on is this:

“const crashpoint = Math.max(1, (2 ** 32 / (int + 1)) * (1 - 0.01))”

Let’s explain this in an example; it’s much easier.

I picked a round that finished with a 5.84X multiplier, and I broke down the result calculation with Stake’s internal calculation tool, which requires you to input the round seed and hash value.

We have already covered the part about algorithms converting the first 16 hexadecimal numbers to decimal numbers. In Stake’s case, only the first 8 Hexadecimal numbers are used to generate a decimal outcome, and you can see the breakdown of the process in the screenshot above.

What ends up being confusing is how the game breaks down the decimal values into the actual game result.

While Stake does provide us with the calculation of their last step in result calculation, they fail to provide any additional information. That’s why I’m here.

Formula from the screenshot example above:

Raw to Edged

4294967296 / (726928685 + 1) * (1 - 0.01) = 5.849291278401964

• 4294967296
  This first value just comes out of nowhere, and Stake has no explanation for it avaliable. It is derived from the game’s combined hash, which consists of 8 hexadecimal digits. 4294967296 represents the maximum value (math.max) for a 32-bit unsigned integer used in Stake’s provably fair algorithm.
• 726928685
  This is the decimal value obtained from converting the game’s combined hash value and its first 8 hexadecimal figures to decimal numbers.
• (726928685+1)
  Adding +1 to 726928685 ensures that the divisor is not zero and prevents division by zero errors. You can’t divide by zero.
• 1−0.01
  This part of the expression accounts for the house edge of Crash by Stake Originals (which is 1%). The 0.01 represents the house edge, which is the percentage of each bet that the house expects to win over the long term.
• 4294967296 / (726928685+1)
  This calculates the base value before accounting for the house edge. It divides the maximum value (4294967296) by the sum of the decimal value (726928685) and 1.
• 4294967296(726928685+1)×(1−0.01)
  This represents the final calculation, which accounts for the house edge. It multiplies the base value by 99% (represented by 1−0.01) to adjust for the house edge.
• Result 5.849291278401964
  This is the final result obtained from the calculation. It represents the game’s final result and the player’s payout!

A similar calculation process is behind the majority of crash games out there. Thankfully, we’re lucky enough to have Stake reveal this publicly.

Conclusion

Provable fairness is simple for the everyday user. Checking the fairness of a modern crash should not take more than 30 seconds. The game is fair if the combination of your seed value and the server seed value returns a hash that equals that of the casino.

If you unveil the curtains behind this technological marvel, you’ll need a lot more than high-school math to understand what’s going on.

My goal with this guide was to break down this concept to a level where a non-computer science person like me could understand how and why I should trust provably fair crash games.