Topic: A guide to how Provably Fair works. - page 2. (Read 12348 times)

The problem is that this solution, will significantly slow down the site, and now relies on two services or more. So it can work, but it will turn out to be very expensive later on.

If that is what is needed to make something provably fair, even for investors, it might work. But then people will have to trust that the two separate servers do not collude.

This might work for a slower game, for example, a card game where people take up to half a minute to think their next move. But again, it introduces a new variable that may deter either players (because they get impatient) or investors (because they have to trust two different people now.)

This problem is almost inevitable.

A potential solution involves using multiple servers controlled by different people to generate the result. Suppose I run a casino/dice-site and you are an investor. Both of us generate a server seed, publish its hash as usual, ask the client to input a client seed (and add a nonce for the number of bets made with this seed). I hash the result and instead of computing the outcome of the bet from this, I transmit the hash, the client seed and the nonce to your server where you hash it with your own server seed. This hash is then used to compute the final outcome.

In this scenario, I don't know your server seed, so I can't predict the outcome of my own rolls and vice versa. Both of us, as well as the client, can recreate the rolls after the server seeds have been published (and verify that they weren't tampered with using the hash that was published before).

I'm not entirely sure if this system is 100% watertight in this form as I didn't think it through very thoroughly, but it gives an indication of the added complications when there is an investor that doesn't necessarily trust the operator not the cheat (and vice-versa). This system is still workable with 1 or several large investors, but with a site like J-D, where anyone can invest, it's not applicable.

Alright, thank you very much.

If I am right there is one problem left: the house could always cheat himself because he knows the server seed. This is particularly an problem if you work with others people's investments.

Sounds good

I just responded 8 seconds before you, mind checking that post out? :-)

You need to use hashing and server / client seeds to determine the result.

Basically: both the server and player must be able to modify the result in an unpredictable way.

Let's see if I understand this completely:

So.. I should make an function that can repeat the results based on the input?

I first show the user our server seed hash, then I let the user generate an user seed (or set it for them).

For the roll I use the server seed (not the hash) and the user seed and the number of the bet since using this server seed. After the rolls I show the server seed and give them a functionality to input that server seed and user seed and roll number to verify the result again.
The user can verify the server seed by hashing it himself, since the chance of duplicate hashes is basicly zero

To make it uncheatable I generate a new server seed whenever the user wants to see the original seed (or change it once a day like said in the first post).

Yes, I agree there must be user part of entropy provided and function of interacting with server entropy disclosed to make sure it leads to unpredictable results.

I know.  And I pointed out a flaw in your answer.

Here's a game.  I'm going to pick numbers between 0 and 100.  You have to guess whether they are below 49.5 or above 50.5.  It has a 1% house edge.

To prove it's fair, using your system, I'm going to provide the hash of the set of numbers I preselected.

It's bcb708ddadd008c0d48a204f2c923c010ac0bbef22aa531b3e8d39bd20ae1fe1

Now play 5 times.

Oh, you lost every bet?  That was unlucky.

Here's the list I hashed, to prove I wasn't cheating:

$ echo -n '49.6 49.7 49.8 50.2 50.4' | sha256sum
bcb708ddadd008c0d48a204f2c923c010ac0bbef22aa531b3e8d39bd20ae1fe1  -

My point is that publishing a hash of numbers you have chosen unfairly doesn't prove fairness.  It just means you have to cheat before the user plays instead of during.

He is asking how to prove a fairless game lol - I answered

All you are proving there is that you picked the results early, and not during play.  It doesn't prove that you picked the fairly.  You could, for instance, have deliberately included long runs of high and low numbers in the result set in order to bust players who always pick the same result (hi or lo, say) and double their bet on loss.

To make it provably fair, allow the user to provide input that affects their results in a repeatable way but which they can't predict.

Create a way to:

1. Create a set of data your numbers picked from
2. Provide a cryptographic seal on that set - show its sha2 hash to customer before game to prove you will not change it
3. Run game
4. Show your original set to player along with its hash and provide open source script to replay all picked numbers on client PC

Well let's change scenario:

If you click play you have an 49.5% of doubling your money.

How can I prove it now?

Choose another game behavior. Heads and tails has 50% probability and zero house edge.

The main benefit of proven fair feature is to prove that house doesn't craft random items during game, but picks really random ones.

So in your case it would be "Provably cheat" game

Hi guys,

Let's say I want to make an heads or tails game, but only with a 49.5% chance to choose the right one (thus making it not a real heads or tails game, but for house edge).
Is it possible to proof I am doing this fair? I am still trying to get an grasp on this whole "provably fair" thing.

For chances I'd like to use the Chance.js (http://chancejs.com) library. I've run simulations and it's pretty accurate.

gives result:

Hi. Great post!

I can explain here caesarbit.eu provably fair implementation variant.

Each game starts from generating server and client seed numbers.

Server generating 50 random numbers and stores them in session providing SHA256 hash of this sequence to client before each game. Player may write down a hash to verify game fairness later. From now server can not change its random seed numbers, as hash will be broken.

Client browser doing the same using Javascript browser capabilities. Player also may write down a browser generated sequence to verify game fairness later.

When this two side random handshake complete, game starts. When server needs to pick a random number, it uses both server and client random number in sequence by doing bitwise XOR operation with two server/client numbers in sequence. Resulting number is used as seed for random engine and random number is picked using this seed.

After game player may visit seed logs for Blackjack or Roulettte and discover server seed sequence verifying its hash.

We provide open source php scripts which may replay all random items in game used particular seed: BlackJack PHP command line tool and Roulette PHP command line tool.

On this page player can find input data for particular game for these scripts. Script will show:
- Server seed
- Server seed hash (verify to written down before game)
- Client seed (verify to written down before game)

And then replays all random game items in sequence they appear in a game.

Thanks for the support. . . . .


Seriously though, I'm just using the words that should be used. It turns out that we still can't prove it, unfortunate as that may be. However it has to be better explained to people or they will call us marketing scams or something.

However, on this topic of using the same seed on multiple rolls, does this logic apply to the same seed (or the same group of seeds linked to each other) on cards games? For example, a 52 card deck that uses 52 different "card seeds" or "card secrets". If you reveal only the cards the player has, how "provable" or "probable" is it that all the other cards are rigged even if you can't see them?

If that question can be satisfied, then we have a partial solution to the poker issue (how to prove that mucked / discarded / folded cards are what they are, because only the original player knows them)... or I ask the other question "if the other player folded, does it matter that you don't know and can't prove what his cards are?"

psst, @dooglus, I made a thread specifically for poker, it's in the games sub-forum. Go there, I could use your input. Thanks.

Back to topic, what is a good level or high enough probability for us to consider as something provable? Certainly 2^16 is not enough, or 2^32 is still only 4 billion. Is 2^64 good enough? 2^80? 2^96? 2^112? Or do we "require" 2^128 at least?

My guess, is that we match what is considered "unbreakable" for the time being, which is 128 bit encryption as the minimum. Implementing something in Triple-DES at 112 bit, while not recommended is also "provably" unbreakable. DES was never cracked. It was simply brute-forced due to such a small key space.

Fortress you are not breaking laws you are helping peoples for good

Well... There are those people who were using Android Wallets that trusted Google's PRNG...

Also, some sites (like Just-Dice and CoinRoll) use the same seed on multiple rolls.  So you need to raise your probability of cheating to the N'th power, where N is the number of rolls with the seed.  The chance of breaking sha512 once is currently so close to zero as to be effectively zero.  Raise that to the 200,000th power (or however many rolls you made with your current JD seed pair) and it just gets silly how tiny the difference between "provably" and "probably" gets.

To put it in perspective, Just-Dice is "probably" fair in the same way as a person sending Bitcoins "probably" owns the private key and didn't just guess it.  Maybe he just got lucky and brute-forced the private key, but "probably" he didn't.