Generating a provably fair crash point

One of the many new break throughs to emerge from the crypto currency space is the idea of provably fair mechanisms. Thanks to Bitcoin and innovators like BitLotto and SatoshiDICE players now have different ways to help ensure that the games they are playing are fair and can be trusted. It would be hard for me to understate the importance of these algorithms. I say this not only because what they are doing for gaming, but also because It seems likely that we are on the heels of some very interesting new use cases in the world of provably fair mechanisms.

At the same time, as with many new technical breakthroughs, they can be difficult to get started on. I ran into numerous hurdles with the original provably fair seeding event for zcrash.io. While some were technical, (embedding an OP_RETURN message in the zcash blockchain was more work than I expected) my primary challenge was explaining to players what exactly it meant and didn’t mean to be “provably fair”.

What I found was that most players had an understanding of the concept of provably fair, and knew that the “crash points should match in the jsfiddle” but things got murky after that. The problem became clear when multiple players called ‘rig’ when our crash points couldn’t be reproduced with the Bustabit jsfiddle/serverSeed.

For that reason, I’ve been meaning write something up about how our provably fair seeding works and where a crash point comes from. It seems especially relevant now as today we are taking ethcrash.io out of beta and seeding the first ever Ethereum based crash game. Before I get to the seeding part though, I think it makes sense to talk about how a crash point is generated.

A basic understanding of how crash games are played will be helpful but isn’t necessary. What’s important to know is that each game has a randomly generated number (crash point) and the players that cashout before the crash point are the winners of that game. I’ve thought a lot about how to best explain this in a concise way and it seems logical to start with a single game’s crash point and work our way backwards from there.

A single crash point is generated

by combining two different sha256 hashes together (just think two pieces of data if you don’t know about one way hashing algorithms like sha256) and turning the resulting piece of data (a single sha256) into a number. That’s really all there is too it! For those that are interested in the specific math, i’ve created a gist that shows the exact javascript.

However, in order to be considered provably fair, we have to pick those two pieces of data (sha256 hashes) in a very specific way. The datas have to be chosen in a way such that neither the house nor the player can predict the resulting crash point. That process takes place like so:

  1. For our first data point (serverSeed), the house will commit to using a given sha256 hash ahead of time*. We will do this by embedding an immutable “commitment” message into the Ethereum block chain. For those that are familiar with the bustabit seeding event, this is an extra step that we’ve added to improve the process by reducing the need to trust a timestamped forum post. Instead, we use the blockchain as a time stamping mechanism.
  2. For the second data point, we need to chose a data point that is completely out of the house’s control. The blockchain also provides us with a nice solution here. In our commitment message from #1, we also commit to using the hashed txid of an upcoming or future block. Given the difficulty of the Ethereum network at this point in time, it would be impossible for us to intentionally select a block who’s hash would result in a favorable chain of games.

*In our example we’re looking at at single game crash point but this process wouldn’t work so well if we had to do it for every single game. For that reason, the serverSeed (again, SHA256 hash) that we commit to using is actually the result of our original serverSeed (house secret) hash back into itself X number of times. Where X equals the number of games that we’ve seeded in this particular ‘game chain’.

While the process can be a bit confusing, it’s really pretty amazing that we are able to prove the fairness of the game using the blockchain and a bit of simple math. We’ve accomplished something that standard casinos have not: we’ve made it impossible for the house or the player to determine ahead of time what the game chain will be and we’ve done so with out relying on ‘trusted’ third party.

It’s important to also note that there are a number of different ways to seed your games in a provably fair way and that while our ‘hybrid Bustabit’ formula does produce a provably fair game chain, it would seem likely that future games will further improve up on it and possibly look toward individual game chains for each user in which the client seed can be regenerated at any time.

Some Final thoughts

  1. Just because a game says it’s provably fair doesn’t mean that it is. Just because a lot of people play on a ‘provably fair’ game doesn’t make it so.
  2. Just because a game has a provably fair mechanism doesn’t mean you should inherently trust the house. I saw a game go up recently in which the site owner (yes, your are responsible for your games as the owner)used the same game chain on two different sites! Of course, a group of savvy players quickly figured it out and were able to predict upcoming games and ‘win’ a quick fortune. The owner chose to not pay out the winners even though it was his mistake. In another case, that same site owner was caught manipulating the 0 crash points. In this case, the hashes told the whole story as they did not match for the ‘rigged’ games. That required someone to actually check the hashes and notice the rig though. Check the hashes from time to time just to be sure.
  3. Haters gonna hate — Some of the players that cry ‘rigged’ at are just trolling for attention or free coin. They have no desire or care to better understand what makes a provably fair game.
  4. Some people just don’t care. I’ve watched people go and play on a site in which the owner has been caught rigging the game. The players know this happened and still play there. ¯\_(ツ)_/¯
  5. There are various different ways to design and implement provably fair mechanisms. This is exciting and it’s fascinating to learn about the different successful and flawed implementations.
  6. Provably fair mechanisms are going to spread beyond crypto gambling games into all kinds of other applications. I see this happening soon and I think it will provide a much needed upgrade to security mechanism across a wide range of platforms.

Fully removing trust in the house

Not util all (or most?) of the game code lives on a blockchain (Ethereum or something like it) in smart contracts AND you can audit it yourself or trust someone that has, will you be able to fully remove trust in the house. It’s happening already and this is something that we at Phantom Labs are very interested in. At that point it will probably make sense to delineate between games that use provably fair mechanism and games that are ‘completely’ provably fair.