Bitcoin Forum
September 16, 2019, 01:16:44 PM
 News: If you like a topic and you see an orange "bump" link, click it. More info.
 Home Help Search Login Register More
 Pages: [1] 2  All
 Author Topic: Concept for Fair Gambling Method  (Read 1017 times)
Mageant
Legendary

Offline

Activity: 1143
Merit: 1001

 November 13, 2013, 10:59:37 PMLast edit: November 15, 2013, 11:50:22 AM by Mageant

I'm working on coin toss game for new a new bitcoin gambling website (coinalot.net) and I am trying to make a provably fair gambling algorithm for it.

I would like your opinion please if the following method would work and if it would be fair and secure.

The Game The game is simply a coin toss. You pick heads or tails. If you guess correctly you get 2x your bet, otherwise you lose your bet. There is a ~1% chance that the coin "lands on the edge". In this case you lose no matter what your pick was (this is the house edge).

Method: 1.) Server secretly generates a random nonce (about 30 characters, letters and digits) and a random whole number 0-98.

2.) Server calculates a hash (eg. sha256) from all this to present to the player on the web page in the next step.

3.) The page is presented to the player with the hash as calculated above, two buttons ("heads" and "tails"), an inputbox to enter his bet amount and another inputbox to enter a number (already filled with a default number 0-98 using javascript). The last inputbox is for the client seed.

4.) The player then clicks on one of the two buttons and the bet is sent to the server. The data sent to the server is "heads/tails" choice, the bet amount, and the number from the second inputbox (client seed).

5.) The server then reveals the nonce, the server number and calculates the result of the bet together with the player input. This calculation can also be done by the player to confirm that everything went fair and that the proper hash was sent originally.

The result is calculated as follows: (server number + client seed) divided by 99 and using the remainder as result (note: integer division).

If this resulting number is 1-49 this means "heads", if 50-98 it means "tails" and a 0 means "edge". If the player picked correctly the payout is made.

Note that a page with a certain hash will timeout after 3 minutes (to avoid giving a long time to calculates hashes).

What do you think? Is this fair?

(note: small correction for step 5)

cjgames.com
1568639804
Hero Member

Offline

Posts: 1568639804

Ignore
 1568639804

1568639804
 Report to moderator
1568639804
Hero Member

Offline

Posts: 1568639804

Ignore
 1568639804

1568639804
 Report to moderator
1568639804
Hero Member

Offline

Posts: 1568639804

Ignore
 1568639804

1568639804
 Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1568639804
Hero Member

Offline

Posts: 1568639804

Ignore
 1568639804

1568639804
 Report to moderator
moderate
Member

Offline

Activity: 98
Merit: 10

 November 13, 2013, 11:40:07 PM

I'm working on coin toss game for new a new gambling website (coinalot.net) and I am trying to make a provably fair gambling algorithm.

I would like your opinion if the following method would work and if it would be fair and secure.

The Game
The game is simply a coin toss. You pick heads or tails. If you guess correctly you get 2x your bet, otherwise you lose your bet.
There is a ~1% chance that the coin "lands on the edge". In this case you lose no matter what your pick was (this is the house edge).

Method:
1.) Server secretly generates a random nonce (about 30 characters, letters and digits) and a random whole number 0-98.

2.) Server calculates a hash (sha224, 100 iterations) from all this to present to the player on the web page in the next step.

3.) The page is presented to the player with the hash as calculated above, two buttons ("heads" and "tails"), an inputbox to enter his bet amount and another inputbox to enter a number (already filled with a default number 0-98 using javascript). The last inputbox is for the client seed.

4.) The player then clicks on one of the two buttons and the bet is sent to the server. The data sent to the server is "heads/tails" choice, the bet amount, and the number from the second inputbox (client seed).

5.) The result is calculated as follows: (server number + client seed) divided by 99 with rest.

If this resulting number is 1-49 this means "heads", if 50-98 it means "tails" and a 0 means "edge". If the player picked correctly the payout is made.

Note that a page with a certain hash will timeout after 3 minutes (to avoid giving a long time to calculates hashes).

What do you think?
Is this fair?

2.) What is the point of doing 100 iterations here ? Why did you decide to use sha224 ? Just to be different ?

3.) You forgot to mention exactly how the input to the hashing function is constructed.

5.) So a client seed of 0 doesn't change the result, this is wrong just because any client seed is supposed to completely change the outcome.

I think you are just trying to make up yet another method.
Mageant
Legendary

Offline

Activity: 1143
Merit: 1001

 November 13, 2013, 11:49:02 PM

I'm working on coin toss game for new a new gambling website (coinalot.net) and I am trying to make a provably fair gambling algorithm.

I would like your opinion if the following method would work and if it would be fair and secure.

The Game
The game is simply a coin toss. You pick heads or tails. If you guess correctly you get 2x your bet, otherwise you lose your bet.
There is a ~1% chance that the coin "lands on the edge". In this case you lose no matter what your pick was (this is the house edge).

Method:
1.) Server secretly generates a random nonce (about 30 characters, letters and digits) and a random whole number 0-98.

2.) Server calculates a hash (sha224, 100 iterations) from all this to present to the player on the web page in the next step.

3.) The page is presented to the player with the hash as calculated above, two buttons ("heads" and "tails"), an inputbox to enter his bet amount and another inputbox to enter a number (already filled with a default number 0-98 using javascript). The last inputbox is for the client seed.

4.) The player then clicks on one of the two buttons and the bet is sent to the server. The data sent to the server is "heads/tails" choice, the bet amount, and the number from the second inputbox (client seed).

5.) The result is calculated as follows: (server number + client seed) divided by 99 with rest.

If this resulting number is 1-49 this means "heads", if 50-98 it means "tails" and a 0 means "edge". If the player picked correctly the payout is made.

Note that a page with a certain hash will timeout after 3 minutes (to avoid giving a long time to calculates hashes).

What do you think?
Is this fair?

2.) What is the point of doing 100 iterations here ? Why did you decide to use sha224 ? Just to be different ?

3.) You forgot to mention exactly how the input to the hashing function is constructed.

5.) So a client seed of 0 doesn't change the result, this is wrong just because any client seed is supposed to completely change the outcome.

I think you are just trying to make up yet another method.

2.)
I'm using sha224 so that sha256 ASICs and programs cannot be used to crack the hash. I could also use sha512 but the hash is very long and I prefer to keep it short.
I'm using 100 iterations just to make it slightly more difficult to crack the hash.

3.)
The input to the hashing function is the nonce concated with ther server number (as a two-digit number).

5.)
Not every client seed has to change the result. It is the (client seed + server seed) div 98 that determines the result.
The player might suspect that the server seed already has the best result rolled for the player in that case he can send a 0 to leave it unchanged. That must be possible, too.

My aim is to make a relatively simple and transparent method. One that a player could easily calculate (except for the hash function).

cjgames.com
moderate
Member

Offline

Activity: 98
Merit: 10

 November 13, 2013, 11:57:25 PM

I'm working on coin toss game for new a new gambling website (coinalot.net) and I am trying to make a provably fair gambling algorithm.

I would like your opinion if the following method would work and if it would be fair and secure.

The Game
The game is simply a coin toss. You pick heads or tails. If you guess correctly you get 2x your bet, otherwise you lose your bet.
There is a ~1% chance that the coin "lands on the edge". In this case you lose no matter what your pick was (this is the house edge).

Method:
1.) Server secretly generates a random nonce (about 30 characters, letters and digits) and a random whole number 0-98.

2.) Server calculates a hash (sha224, 100 iterations) from all this to present to the player on the web page in the next step.

3.) The page is presented to the player with the hash as calculated above, two buttons ("heads" and "tails"), an inputbox to enter his bet amount and another inputbox to enter a number (already filled with a default number 0-98 using javascript). The last inputbox is for the client seed.

4.) The player then clicks on one of the two buttons and the bet is sent to the server. The data sent to the server is "heads/tails" choice, the bet amount, and the number from the second inputbox (client seed).

5.) The result is calculated as follows: (server number + client seed) divided by 99 with rest.

If this resulting number is 1-49 this means "heads", if 50-98 it means "tails" and a 0 means "edge". If the player picked correctly the payout is made.

Note that a page with a certain hash will timeout after 3 minutes (to avoid giving a long time to calculates hashes).

What do you think?
Is this fair?

2.) What is the point of doing 100 iterations here ? Why did you decide to use sha224 ? Just to be different ?

3.) You forgot to mention exactly how the input to the hashing function is constructed.

5.) So a client seed of 0 doesn't change the result, this is wrong just because any client seed is supposed to completely change the outcome.

I think you are just trying to make up yet another method.

2.)
I'm using sha224 so that sha256 ASICs and programs cannot be used to crack the hash. I could also use sha512 but the hash is very long and I prefer to keep it short.
I'm using 100 iterations just to make it slightly more difficult to crack the hash.

3.)
The input to the hashing function is the nonce concated with ther server number (as a two-digit number).

5.)
Not every client seed has to change the result. It is the (client seed + server seed) div 98 that determines the result.
The player might suspect that the server seed already has the best result rolled for the player in that case he can send a 0 to leave it unchanged. That must be possible, too.

My aim is to make a relatively simple and transparent method. One that a player could easily calculate (except for the hash function).

2.) Are you serious about this ? I can't believe you are serious, clarify this please. Do you think ASICs will find a collision that easy ? Do you understand the probabilities involved here ? Yes, lots of questions, but if the answer to the first one is "no" then I just missed you were joking.

5.) Yes, every client seed has to completely change any result the server may have decided by itself. That is a big part of being provably fair.

So I take that all the current methods you checked were hard or at least non-transparent to the players ? If that is the case you might want to list the methods you checked and skipped.
Remember remember the 5th of November
Legendary

Offline

Activity: 1862
Merit: 1002

Reverse engineer from time to time

 November 13, 2013, 11:58:48 PM

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
Mageant
Legendary

Offline

Activity: 1143
Merit: 1001

 November 14, 2013, 12:08:58 AM

From what I have read the entropy of the random number generator in PHP is only 2 billion (the number of possible seeds). That is unless you use some special source of random numbers which will not necessarily be available to my server.

Please correct me if I am wrong, but a set of ASICs can do easliy several GHASH/s so it seems feasible to me that they could try out all possible seed numbers and knowing/guessing which algorithm I am using to generate the nonce. It therefore seems prudent to me not use sha256 as the hashing algorithm.

It don't see why *every* client seed has to change the result. In fact since there are only 3 possible outcomes (heads, tails, edge) there will always be a certain number of client seeds that will not change the result. The thing is though that the server cannot know in advance which seed it will get from the client. The client just has to have the possibility of changing the result in an (for the server) unpredictable way.

There is no way I can see in this method that the server can choose a result in advance even if totally manipulated, to get a certain "desired" outcome.

cjgames.com
Remember remember the 5th of November
Legendary

Offline

Activity: 1862
Merit: 1002

Reverse engineer from time to time

 November 14, 2013, 12:13:07 AM

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
moderate
Member

Offline

Activity: 98
Merit: 10

 November 14, 2013, 12:13:58 AM

PHP just jumped in the mix, you never mentioned that before. I'm afraid you shouldn't be coding this at all.
Mageant
Legendary

Offline

Activity: 1143
Merit: 1001

 November 14, 2013, 12:18:05 AM

PHP just jumped in the mix, you never mentioned that before. I'm afraid you shouldn't be coding this at all.

Why is that?

cjgames.com
moderate
Member

Offline

Activity: 98
Merit: 10

 November 14, 2013, 12:22:52 AM

PHP just jumped in the mix, you never mentioned that before. I'm afraid you shouldn't be coding this at all.

Why is that?

It is just my opinion based on the previous replies, it looks like the future users are going to get into trouble by using your coinalot.com (but the domain name is cool).

There are only three results, but if the client seed doesn't completely change the outcomes in a way the server cannot predetermine then the server can just pick the most appropriate seeds for itself.
Mageant
Legendary

Offline

Activity: 1143
Merit: 1001

 November 14, 2013, 12:23:02 AM

It is somewhat similar, but not quite. Sending a certain pre-generated client seed to the client's browser instead of using one created in the browser itself (using javascript) would be noticeable by someone observing the traffic.

That is a problem that all browser-based provably fair gambling sites have AFAIK.

Also I don't have the other problem mentioned there because I generate a new nonce/hash for every bet.

cjgames.com
Remember remember the 5th of November
Legendary

Offline

Activity: 1862
Merit: 1002

Reverse engineer from time to time

 November 14, 2013, 12:25:51 AM

It is somewhat similar, but not quite. Sending a certain pre-generated client seed to the client's browser instead of using one created in the browser itself (using javascript) would be noticeable by someone observing the traffic.

That is a problem that all browser-based provably fair gambling sites have AFAIK.

Also I don't have the other problem mentioned there because I generate a new nonce/hash for every bet.
It was a server-side pre-generated seed, not client-side. Thus no way you can know.

Quote
I generate a new nonce/hash
That's the thing. You shouldn't generate anything.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
Mageant
Legendary

Offline

Activity: 1143
Merit: 1001

 November 14, 2013, 12:28:56 AM

PHP just jumped in the mix, you never mentioned that before. I'm afraid you shouldn't be coding this at all.

Why is that?

It is just my opinion based on the previous replies, it looks like the future users are going to get into trouble by using your coinalot.com (but the domain name is cool).

There are only three results, but if the client seed doesn't completely change the outcomes in a way the server cannot predetermine then the server can just pick the most appropriate seeds for itself.

The client seed does completely change the result, but not *every* client seed.
If I secretly pick a number and you secretly pick a number then I cannot predict (with greater than 50% probability) whether the sum of our two numbers will be odd or even.
If you should pick a 2 then your 2 does not change the odd/eveness of the result. For you a "2" thus does not change the outcome, yet it is still unpredictable to me.

cjgames.com
Mageant
Legendary

Offline

Activity: 1143
Merit: 1001

 November 14, 2013, 12:33:24 AM

PHP just jumped in the mix, you never mentioned that before. I'm afraid you shouldn't be coding this at all.

Why is that?

It is just my opinion based on the previous replies, it looks like the future users are going to get into trouble by using your coinalot.com (but the domain name is cool).

BTW, there will be other games too, not just this one.
Glad you like the domain name.

cjgames.com
moderate
Member

Offline

Activity: 98
Merit: 10

 November 14, 2013, 12:37:14 AM

PHP just jumped in the mix, you never mentioned that before. I'm afraid you shouldn't be coding this at all.

Why is that?

It is just my opinion based on the previous replies, it looks like the future users are going to get into trouble by using your coinalot.com (but the domain name is cool).

There are only three results, but if the client seed doesn't completely change the outcomes in a way the server cannot predetermine then the server can just pick the most appropriate seeds for itself.

The client seed does completely change the result, but not *every* client seed.
If I secretly pick a number and you secretly pick a number then I cannot predict (with greater than 50% probability) whether the sum of our two numbers will be odd or even.
If you should pick a 2 then your 2 does not change the odd/eveness of the result. For you a "2" thus does not change the outcome, yet it is still unpredictable to me.

You are missing the point. EVERY client seed has to completely change the result, so the server cannot predict in any way the possible result before taking that into consideration. Scrap this idea you got.
Mageant
Legendary

Offline

Activity: 1143
Merit: 1001

 November 14, 2013, 02:07:55 PM

Anybody else care to comment?

cjgames.com
Eternity
Full Member

Offline

Activity: 196
Merit: 100

 November 14, 2013, 09:15:36 PM

Can you elaborate what does the term actually mean ?
Mageant
Legendary

Offline

Activity: 1143
Merit: 1001

 November 15, 2013, 09:39:31 AM

Can you elaborate what does the term actually mean ?

Normally with online gambling you have to trust the operator not to cheat, because the operator could generate manipulated numbers.

Provably fair gambling means that the operator can prove mathematically that he is not cheating.

This means that the given odds of losing/winning in the game are really so.

cjgames.com
tonino
Sr. Member

Offline

Activity: 348
Merit: 250

 November 15, 2013, 11:29:29 AM

Can you elaborate what does the term actually mean ?

Normally with online gambling you have to trust the operator not to cheat, because the operator could generate manipulated numbers.

Provably fair gambling means that the operator can prove mathematically that he is not cheating.

This means that the given odds of losing/winning in the game are really so.

I agree fully with Your provably fair definition.  where is the solution?
Mageant
Legendary

Offline

Activity: 1143
Merit: 1001

 November 15, 2013, 11:49:30 AM

Can you elaborate what does the term actually mean ?

Normally with online gambling you have to trust the operator not to cheat, because the operator could generate manipulated numbers.

Provably fair gambling means that the operator can prove mathematically that he is not cheating.

This means that the given odds of losing/winning in the game are really so.

I agree fully with Your provably fair definition.  where is the solution?

My solution is the method I wrote in the first post of this thread.
I put it here for scrutiny by others.

cjgames.com
 Pages: [1] 2  All