Would appreciate a quick sanity check...

vineyard

hero member

Activity: 546

Merit: 500

EOS Auctions

Quote from: Rannasha on February 13, 2014, 03:20:24 PM

This scheme indeed proves that the result was not altered after the player made his picks.

However, it does not prove that there isn't a system on the server that tries to predict the players moves. If a returning player often picks a certain spot, it can be beneficial for you to generate a ticket has a cross on that spot. Or simply using analysis on the set of all plays: Set spots that get picked the most to contain a cross.

To exclude this possibility and create a true provably fair game you need to:
1) Generate a server seed, show the player its hash.
2) Ask the player for a client seed. This can be pregenerated by something like a JavaScript PRNG with an option for the player to change it manually (this is how most dice-sites do it).
3) Generate the ticket using the server seed, the client seed and possibly a nonce value (if a nonce is used, it must be visible to both parties).
4) The player plays.
5) After the game, the player can either play again (go to step 3, with new nonce value of course) or request the server seed. In this case, show the server seed and go back to step 1.

The algorithm that you use to generate the ticket has to be public. The player has to be able to generate the ticket in the same way the server did and obtain the same result.

Thank you. This is hugely helpful. We obviously don't have a system looking for patterns globally or at particular players, but I clearly see your point. We will appropriately revise before opening up at a large scale.

Thanks again...

Rannasha

hero member

Activity: 728

Merit: 500

This scheme indeed proves that the result was not altered after the player made his picks.

However, it does not prove that there isn't a system on the server that tries to predict the players moves. If a returning player often picks a certain spot, it can be beneficial for you to generate a ticket has a cross on that spot. Or simply using analysis on the set of all plays: Set spots that get picked the most to contain a cross.

To exclude this possibility and create a true provably fair game you need to:
1) Generate a server seed, show the player its hash.
2) Ask the player for a client seed. This can be pregenerated by something like a JavaScript PRNG with an option for the player to change it manually (this is how most dice-sites do it).
3) Generate the ticket using the server seed, the client seed and possibly a nonce value (if a nonce is used, it must be visible to both parties).
4) The player plays.
5) After the game, the player can either play again (go to step 3, with new nonce value of course) or request the server seed. In this case, show the server seed and go back to step 1.

The algorithm that you use to generate the ticket has to be public. The player has to be able to generate the ticket in the same way the server did and obtain the same result.

vineyard

hero member

Activity: 546

Merit: 500

EOS Auctions

For a long time I have been fascinated with the concept of "provably fair" gambling using Bitcoin. I think it is great to offer games where people can have fun betting while knowing they are not getting ripped off. I am about to open up a new site I have developed that lets people bet on scratchtickets. They are asked to reveal 6 hidden

symbols before revealing 9

symbols. You can see the game (and play if you want) @ bitcoin-scratchticket.com.

Here is the description as to why the games are provably fair:

Provably fair means that once a bet has been placed and a scratchticket game has started, the locations of the

and

symbols remain fixed and cannot be altered.

When a bet is placed and a game is started, our servers randomly hide 6

symbols and 9

symbols in the scratchticket. Two character strings are then created:

A random "secret key" made up of 64 characters is created and stored on our servers. This "secret key" is not disclosed to the player until the game ends.
A 15 character string of "1"s and "0"s is created to represent the locations of the symbols on the scratchticket. A "1" represents a symbol, and a "0" represents a symbol. The sequnce of the "1"s and "0"s in the string map to the locations on the scratch ticket as shown in the picture.

For example, the 15 character string for the following scratchticket would be "111000000010011".

Finally, a public hash is created by concatenating the two strings and then taking the sha256 hash. Here is an example of the PHP code that performs this operation.

Code:

$public_hash = hash("sha256", $secret_key . "111000000010011");

At the start of the game, this public hash is displayed at the bottom of the scratchticket and remains unchanged.

When the game ends, the public hash displayed at the bottom of the scratchticket becomes a clickable link. When clicked, the "secret key" is revealed. A player can prove that the locations of the symbols were not changed during game play by taking the following steps.

Create a string of "1"s and "0"s representing the symbols on the scratch ticket in the same fashion as described above.
Concatenate the revealed private key with the "1"s and "0"s pattern and produce its sha256 hash (as shown in the PHP code above).

The result will equal the public hash that was displayed on the scratchticket at the start of the game. This proves the scratchticket was not altered because changing the locations of the symbols on the scratchticket would produce a different string of "1"s and "0"s. A different string of "1"s and "0"s would produce a different sha256 hash than the public hash that was displayed on the scratchticket when the game started.

Does this all make sense and prove that the game is fair?

Thanks in advance for your help...

Topic: Would appreciate a quick sanity check... (Read 615 times)