How would I go about making a provably fair system?

[matt_boyd]

It would seem that I don't know that much about provably fair systems as this was my first attempt; "http://matt-boyd.co.uk/dice" If anyone would like to contribute / help me, that would be more than awesome for sure!

Also if anyone would actually be interested in playing a game like this, I have other games in mind with different odds, I just need to make sure that I get the fair mechanism and the payments ready, however I am struggling with both.

Additionally, if anyone could give me an estimate to the amount of BTCs the site would fetch when finished, that would be awesome.


Thanks, Matt.

[JonnyBravo]

Give us a clue mate! Not immediately apparent from that what problem you're having. How are you deciding the result?

[Kruncha]

Maybe have a look at this http://www.random.org/clients/http/

May be of some use to you.

Good luck

K.

[JonnyBravo]

heheh -- was just having a look at that myself

I don't think I see a provably fair way to use that service, though do correct me if I'm missing something.

Even if they offered a hash my users could go and look up (and I don't see any functionality like that), there's no guarantee I didn't generate a few random numbers until I got one that gave my desired result.

Given that transaction IDs can be affected by the player, they're only suitable for raffle style situations. I really like the www.bitcoincrown.com solution:

Your winning odds are provably fair. After the confirmation of your payment, your transaction hash and the merkle root of the block containing it are used to create hmac_sha512(merkleroot,txhash). If the decimal of the first two bytes of this hash are less than 983 then you reset the Bitcoin Crown. This cannot be predicted and easily verified!

Anyone who knows of a simpler solution that is still provably fair, I'd love to hear about it Perhaps the OP found one?

[matt_boyd]

heheh -- was just having a look at that myself

I don't think I see a provably fair way to use that service, though do correct me if I'm missing something.

Even if they offered a hash my users could go and look up (and I don't see any functionality like that), there's no guarantee I didn't generate a few random numbers until I got one that gave my desired result.

Given that transaction IDs can be affected by the player, they're only suitable for raffle style situations. I really like the www.bitcoincrown.com solution:

Your winning odds are provably fair. After the confirmation of your payment, your transaction hash and the merkle root of the block containing it are used to create hmac_sha512(merkleroot,txhash). If the decimal of the first two bytes of this hash are less than 983 then you reset the Bitcoin Crown. This cannot be predicted and easily verified!

Anyone who knows of a simpler solution that is still provably fair, I'd love to hear about it Perhaps the OP found one?

OP is yet to find anything. The problem that I am having is that it shows the hash of the current result on the screen instead of the next one.

Here is an example of what I am working with.

Code:

$random= mt_rand(1,6); //Create a random number between 1 and 6.
$string = "TvG5hs3";
$output = hash('SHA256', $random); //Hashing the random number with SHA256
$salt = substr(str_replace('+', '.', base64_encode(pack('N4', mt_rand(), mt_rand(), mt_rand(), mt_rand()))), 0, 22);
echo $salt. $random. $string .$output; //Outputting the hash.

[JonnyBravo]

Matt,

Try something like this (PHP).

You would only roll the dice when a user deposits; so you'd probably have a cron job looking for new deposits, and then when one happens:

Code:

// Fire up a JSON client
$client = new jsonRPCClient($json_url);
// Get the transaction
$transactions=$client->listtransactions("account-name-of-account-user-deposited-into",1);
// Grab the block hash (can't be predicted by us or user) and transaction ID
$blockhash = $transactions[0]['blockhash'];
$txid = $transactions[0]['txid'];
// Hash the block hash with the transaction ID as a key
$hash = hash_hmac("sha512",$blockhash,$txid);
// Convert the first hex digit of the hash to an int
$diceRoll = hexdec(substr($hash,0,1));

Boom, $diceRoll now contains a provably fair number between 0 and 15 inclusive.

[matt_boyd]

Okay, this is interesting, erm, would it be possible for you to hope on webchat.freenode.net, #matt_bitcointalk and guide me a little bit? Thanks, Matt.

[JonnyBravo]

Sure

[matt_boyd]

Hey man, any chance you could hop on freenode #matt_server to explain what IRC you are on?

[SRoulette]

You are welcome to reuse our provably fair RNG.

Below is the bet verifier with is a command line application players can use to confirm results. It would be very simple to modify this to use a players txid + secret to generate any random number range you want.

More information is available in our FAQ: http://satoshiroulette.com/FAQ.php

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: confirm_bet.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;

[matt_boyd]

Thanks very much Sroulette, I remember talking to you on Reddit!


I shall have a look into it later, much appreciated,

Matt!

[SRoulette]

Thanks very much Sroulette, I remember talking to you on Reddit!


I shall have a look into it later, much appreciated,

Matt!

glad to see you are still at it