Topic: How does provably fair work? (Read 1932 times)

Hey Boelens, you can use my site, http://bitcoinmaniac.com/verify as an easy tool to verify bets on some of the top sites. It's open source javascript, so it can be verified.

Satoshidice also uses a daily secret. You can manipulate your transaction hash to a certain extent, such as not broadcasting one, redo it, then broadcast that one for whatever reason. But combined with a site secret, your roll effectively becomes random.

SD was one of the first blockchain based dice games. It's method is the gold standard.

Some good answers here, something else I'd like to put out there to you all

In one-off dice games, where there is a single bitcoin transaction used per game.

Would the transaction ID be an acceptable seed for generating a winning number?

Or are transaction id's predictable/manipulatable ?

Thanks!

Also, if the game or site uses secrets (from a third party) that they themselves do not know, but only know the hash, then that is also perfectly provably fair. Even third party sites that do not publish a hash, but publish repeatable random numbers to be used as seeds can be used, such as the randomization feature of random.org.

You can get the same sequence of random numbers or random bytes from the server of a previously revealed collection of random numbers, but you can't get future sequences that have not yet been made available. Obviously, no one can get a hash of such future secrets since they are generated completely randomly from atmospheric noise. This isn't applicable to real-time games such as dice though.

There is some research into how this can be done, so even the owner of a dice site can't know the secrets needed, but the way it is now, if attempted, is going to produce a bottleneck and slow down the site.

That was an excellent explanation - that should be published in a wiki or something.

It works similarly on all provably fair sites, pretty much.

1. the server picks a random "server seed"

2. the server shows the user a hash of the server seed

3. the player picks their own seed, the "client seed"

4. the server uses the server seed and the client seed to generate the outcome of the game

5. the server publishes the server seed

Notice that it's important that 1. comes before 3.  The player picks last, so there's no way the site can influence the rolls.

Once all five steps are complete, the player can check that:

a) the server seed published in step 5 does in fact hash to the string that was shown in step 2, and
b) the client seed (step 3) and server seed (step 5) do in fact generate the shuffle, roll, spin, or whatever that happened in the game (step 4)

That's all.  Some sites (satoshidice, coinroll) change the server seed every 24 hours.  Some sites (primedice, bitzino) change it every roll.  Some sites (just-dice) change it on demand.  I prefer the last way - 24 hours is a long time to wait to verify a suspicious roll, but changing the seed every roll makes for a lot of work for the player, making a note of each hash, verifying each seed, etc.

For Just-Dice, there's a user-contributed script at http://jsfiddle.net/Zq8tL/3/ which lets you tell it the client seed and server seed, and outputs all the rolls those seeds generate.  So you can check it against the rolls you actually saw and make sure there's nothing fishy going on.

---
Edit on 28 Nov 2013: at the end of September 2013, from bet 145 million onwards, the algorithm used to generate rolls was changed and so the above-linked jsfiddle script no longer works.

There's a new verifier linked from the bottom of the 'Fair?' tab which is able to apply both the old and new algorithms, and defaults to the new one.
---

The server seed is unknown, but the hash is revealed.
The client seed is something you set, after the server seed has already been generated.

You play the game. Results are based on the server seed and the client seed.

After the game, the server seed is revealed. You can now verify that the hash of the server seed is correct.
You can now compute the result of the game because you have all the variables.

You have just proven to yourself, that the game is fair. Provably Fair.

would the hash generated be based on anything, such as blocks mined?

How can we check this hash when the game is over, or is it kept tp the owner?

okay, on bitzino's site

regarding the roulette game, how does having the client seed and hash(secret) prove that it is a provably fair game?


how does this completely rule out other software gimmicks?

The problem is that every site has a different implementation. They do have instructions on how to do it manually, and the bigger sites have third party verification scripts, where you see the source code and what it does, and how it computes.

In my lotto, for example, it is provably fair because:
1. everyone knows what I am going to do.
2. everyone knows the secrets that I will use.
3. no one knows all the secrets until the draw date.

Huh, that's strange, that nobody bothers to make it. I can see there being demand for it. Thanks for the answer!

If you did some searching, you would know that provably fair works by publishing the hash of a secret before a game. After the game, the secret is released and can be compared to the result. Publishing the hash of the secret prevents the operator from changing the secret and by extension, the result of the game.

no one bothers to make it

I have a question, how exactly does provably fair work? I've wondered for a while, and how can I verify if it is provably fair? It would be awesome if there was some sort of plugin for Chrome/Firefox that would automatically check if it was provably fair.