You're playing a simple dice game, where the site generates a lucky number for each bet. The problem is, how do you know the site is generating random numbers fairly? How do you know they're not cheating or rigging the game? They could be secretly making you lose more often.
The solution: Provably Fair games.
HashingA hash is a message digest. It summarizes a message one way - you can't find out what the original message was from a hash, unless you brute force everything. Take "hello", the sha256 (an hashing algorithm) hash of that is "2cf24dba5fb0a30e
[..]". Add a space to the end, "hello " and you get "5e3235a8346e5a4585f8c5
[..]". So you can see changing a tiny part makes it completely different - random mapping.
The important part is hashes are one way, and are unpredictable. If I give you a hash of a very long string of numbers (say, 30 digits), you can't tell me what the original numbers are from the hash. (You actually theoretically can, by trying out all the numbers from 0000..00 to 9999..99, but it's implausible with a large search space).
Hashes are also tamper resistant. I can't find another number that gives the same hash. So you know I can't change my responses. (You actually can, it's called hash collisions, but the chances of that happening are 8.64e-78 which means it won't happen in real life for all intents and purposes.)
Provably FairnessLet's say I run a blackjack game.
[Ad: play blackjack on bitzino] I could provide a hash of the deck. But that only tells the player I haven't changed the deck after showing the hash, I could swapped cards in the deck beforehand. To solve this, the player needs to be able to influence the results of the deck. Here's where provably fairness comes in.
Outcome = hash(dealerSecret + playerSecret)
Outcome can be determined in any way, as long as it's public. Maybe first four pairs of numbers in the outcome are winning lotto numbers. Maybe first bit == 0 means heads, first bit == 1 means tails. Doesn't matter, because SHA256 is effectively a random mapping function.
The site hashes their randomly generated secret (they can generate it any way they wish, but if it is not random then the player will be able to beat the house and the site goes bankrupt) and shows it to the player. This way, the player knows the site isn't changing their secret after the player sends their secret to the site.
The dealer secret sometimes is hashed and presented before each play (eg bitZino, BitVegas), or it is generated well in advance - one secret for each day. The hashes of each day's secrets are published, and the actual secret is revealed after the day is over (so players can't cheat). This is used on sites like satoshiDICE.
For the player's secret, it could be generated in the browser via javascript, with an option for the player to specify it for themselves, or for blockchain games it uses the transaction ID. The transaction ID is just a hash of the transaction sent. The player needs to be able to change their secret (which you can do with transactions, by not sending a TX with a secret you don't like for some odd reason).
No player secretsSome types of games don't need player secrets. They just need to hash their outcome and show you that before you play. Take coin flipping - IF you can bet on heads or tails. Sure, the site might have heads come up 55% of the time, but players will be able to perform statistical analysis and start betting on heads all the time and the house goes bankrupt. (Nitpick: Site can actually rig it, by giving heads more often if you bet more often on tails for example and vice versa, but that can be exploited with different bet amounts by the player -> site goes bankrupt)
Another example is minesweeper/minefield. Mines are predetermined. You choose which squares to dig. In either of those examples, you don't need to influence the result with a secret - you already are influencing the result by deciding which square to click or heads/tails to bet upon. So those sites are provably fair without requiring secrets exchange.
