|
Title: Would appreciate a quick sanity check... Post by: vineyard on February 13, 2014, 07:53:58 PM 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 https://bitcoin-scratchticket.com/public/website/images/scratchticket_themes/1_6/default/hit-box-1.png symbols before revealing 9 https://bitcoin-scratchticket.com/public/website/images/scratchticket_themes/1_6/default/miss-box-1.png symbols. You can see the game (and play if you want) @ bitcoin-scratchticket.com (https://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 https://bitcoin-scratchticket.com/public/website/images/scratchticket_themes/1_6/default/hit-box-1.png and https://bitcoin-scratchticket.com/public/website/images/scratchticket_themes/1_6/default/miss-box-1.png symbols remain fixed and cannot be altered. When a bet is placed and a game is started, our servers randomly hide 6 https://bitcoin-scratchticket.com/public/website/images/scratchticket_themes/1_6/default/hit-box-1.png symbols and 9 https://bitcoin-scratchticket.com/public/website/images/scratchticket_themes/1_6/default/miss-box-1.png symbols in the scratchticket. Two character strings are then created:
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.
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... Title: Re: Would appreciate a quick sanity check... Post by: Rannasha on February 13, 2014, 08: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. Title: Re: Would appreciate a quick sanity check... Post by: vineyard on February 13, 2014, 08:34:25 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... |
