A guide to how Provably Fair works.

[masterluc]

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.

[m19]

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).

[🏰 TradeFortress 🏰]

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

Well let's change scenario:

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

How can I prove it now?

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.

[m19]

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

Well let's change scenario:

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

How can I prove it now?

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.

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

[🏰 TradeFortress 🏰]

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 generate the user seed on the client with Javascript).

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).

Sounds good

[m19]

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.

[Rannasha]

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.

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.

[Dabs]

A potential solution involves using multiple servers controlled by different people to generate the result.

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.)

[Rannasha]

A potential solution involves using multiple servers controlled by different people to generate the result.

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.)

Indeed. Setting up a service that is provably fair for both players and investors is rather tricky.

In the end though, you can't get around trusting the operator of the site if you're investing (and also if you're playing), because the operator might just as well run off with the coins.

[escrow.ms]

That's a great guide TF.  Thanks.

[VII]

Where would I get a provably fair system coded like this? For a dice game that rolls the sum of two six-sided dice?

[Benson Samuel]

Take your client seed (c650067f5558ada79196dfd45a1de76b), add the shuffled transaction hash/ id from your payment (cb9a5905f361c8adb66609c0056c0c33oa93d986ea670198c4d651178c4e1i66) and hash it using SHA256 (64e602175c43187d2ca420bd6dc415ad0cd03247ac8635ca51232f03488f8f04) . We then select the first x numbers in that string and set that as the provable result. In this case: The winning combination is 6,4,6,etc

Assuming that the server seed has been taken from Blockchain entropy which is completely verifiable, is this PF with PR? The player can be presented the shuffled hash after each spin and can set his client seed before each spin.

[adaseb]

provably fair can't be predict.
but sometimes i have picked number by using

SHA256 hash of the secret of the next game: 76F1077B654E147B27FAF03EEF4D286C1B4E3AAA000849B76D3BDA8FFE2D598F

there are 64 strings.
 take first 4 char 76F1
break them by using your own mind how you can break that number?
 7+6+6+1 = 20
077B
7+7+2= 16 and so on.

note use a=1 b=2 and so on.

Why in the world did you bump this 4 year old thread. I actually remember reading this thread about 4 years back.

Someone really should start locking and archiving certain threads because they are irrelevent in some topics.

[dooglus]

provably fair can't be predict.
but sometimes i have picked number by using

SHA256 hash of the secret of the next game: 76F1077B654E147B27FAF03EEF4D286C1B4E3AAA000849B76D3BDA8FFE2D598F

there are 64 strings.
 take first 4 char 76F1
break them by using your own mind how you can break that number?
 7+6+6+1 = 20
077B
7+7+2= 16 and so on.

note use a=1 b=2 and so on.

What are you trying to do here? Why would you sum the digits of groups of characters from a hash?

And why use a=1, b=2 when a represents 10 and b represents 11?

I think you may as well just play randomly than think that your algorithm is helping you at all.

[Skirame]

Excellent summary, thanks for the sharing!

[ReLieD]

I don't know . Even if I read that it's probably fair and stuff and even if someone shows me all the proofs required even then I will feel that everything in rigged and it's not fair. I don't know , it's just a personal feeling

[Dabs]

You have to understand how the proof works. When you do understand it and the variables, and how much control or influence you have over the results, then you know that is is fair. Provably fair. Your feelings at that point don't matter, because it's all math and numbers don't lie.

In the case of live dealers or live lotteries, ... it's like the analog equivalent of provably fair. What you feel here depends on how good the video is, or if there are camera tricks, or something. Trying to get a hash collision or rigging a provably fair game is much more difficult.

[PizzaBTC]

I don't know . Even if I read that it's probably fair and stuff and even if someone shows me all the proofs required even then I will feel that everything in rigged and it's not fair. I don't know , it's just a personal feeling

You may be right. I think there is nothing fair in the world of gambling. If anyone is saying this thing that he is playing a fair game, he is definitely telling alien then. Being fair and dealing, gambling are entirely opposite and are just like having inversely proportional relation in between them.

[Dabs]

It's fair in the sense that both the operator or website and the player have no direct control of the outcome. The chance of winning or losing applies on the games.

If you play a lottery type game with 1% chance of winning, and you lose almost all the time (or 99%) that's fair. The house edge is different from the fairness of the game, as that is one aspect where the casino makes money, but at least you know that from the beginning.

What is being talked about here is the unpredictability of random number generation but at the same time verifiable after the fact.

[lottoken@lottoken.org]

All, great thread and discussion. We ran into the same problems and invented a patent-pending algorithm to solve it. Please visit us http://lottoken.org to learn more. Our white paper is at http://bit.ly/lottoken_wp.  We have even live contracts deployed for our platform.