Excellent summary of provably fair.
Keep on spreading the word so that eventually players avoid sites that prefer to manipulate/cheat.
Topic: A guide to how Provably Fair works. - page 5. (Read 12402 times)
Nice work Fortress.
BitVegas has an interesting take on this. The multiplayer blackjack game takes the last thing each player said in the chat as the player seed, appending them all together. So every player gets to influence the shuffle if they like.
BitVegas is a truly impressive project.
to ensure even number distribution we recommend using something similar to our provably fair RNG which is a a combination of hmac_sha512 + Mersine Twister:
Code:
#!/usr/bin/perl -w
# bet_verify.pl
use strict;
use warnings;
use Digest::SHA qw(hmac_sha512_hex);
use Math::Random::MT;
if(!$ARGV[0] || $ARGV[0] eq "--help" || $ARGV[0] eq "-h" || $ARGV[0] eq "/?")
{
print "usage: bet_verify.pl\n";
exit;
}
my $range=$ARGV[0];
my $secret=$ARGV[1];
my $tx=$ARGV[2];
my $seed = Digest::SHA::hmac_sha512_hex($tx, $secret); # hash txid and secret
$seed =~ s/^(.{8}).*$/$1/; # use 1st 8 characters of hash for secret
$seed = hex($seed) + 0; # convert hex to number
my $gen = Math::Random::MT->new($seed); # seed MT
my $number = int($gen->rand($range)+1); # generate random result inside game range using seeded MT
print "Result: $number\n";
exit;
BitVegas has an interesting take on this. The multiplayer blackjack game takes the last thing each player said in the chat as the player seed, appending them all together. So every player gets to influence the shuffle if they like.
Not the best way to do provably fairness. When the block reward halves to 12.5 BTC, you better make sure there are no bets > 12.5 BTC otherwise mining pools can cheat by discarding blocks.
This is only one method which can be used in multiplayer games (raffles and lotteries).To prevent cheating from miners you should generate secret string and use combination of hash(secret + block_hash) to determine the winner.
Not the best way to do provably fairness. When the block reward halves to 12.5 BTC, you better make sure there are no bets > 12.5 BTC otherwise mining pools can cheat by discarding blocks.
This is only one method which can be used in multiplayer games (raffles and lotteries).To prevent cheating from miners you should generate secret string and use combination of hash(secret + block_hash) to determine the winner.
Not the best way to do provably fairness. When the block reward halves to 12.5 BTC, you better make sure there are no bets > 12.5 BTC otherwise mining pools can cheat by discarding blocks.
This is only one method which can be used in multiplayer games (raffles and lotteries).To prevent cheating from miners you should generate secret string and use combination of hash(secret + block_hash) to determine the winner.
Not the best way to do provably fairness. When the block reward halves to 12.5 BTC, you better make sure there are no bets > 12.5 BTC otherwise mining pools can cheat by discarding blocks.
This is only one method which can be used in multiplayer games (raffles and lotteries).To prevent cheating from miners you should generate secret string and use combination of hash(secret + block_hash) to determine the winner.
I know some sites that use the block time as the seed to be hashed.
Another approach is to use hash of the next Bitcoin block, coming right after all bets were made.
Not the best way to do provably fairness. When the block reward halves to 12.5 BTC, you better make sure there are no bets > 12.5 BTC otherwise mining pools can cheat by discarding blocks.
Another approach is to use hash of the next Bitcoin block, coming right after all bets were made.
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.
Hashing
A 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 Fairness
Let'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 secrets
Some 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.
The solution: Provably Fair games.
Hashing
A 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 Fairness
Let'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 secrets
Some 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.
Jump to: