Topic: Concept for Fair Gambling Method (Read 1176 times)

to be frank I have no clue if Your version is acceptable or not, I hope there will be more activity and tips from some other experts

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

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

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.

Can you elaborate what does the term actually mean ?

Anybody else care to comment?

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.

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

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.

It was a server-side pre-generated seed, not client-side. Thus no way you can know.

That's the thing. You shouldn't generate anything.

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

Why is that?

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

Read this thread https://bitcointalksearch.org/topic/is-primedice-really-provablyfair-253144 from what I gather, it is similar.

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.

Anything that is generated by the server allows the operator to manipulate. I can already see myself posting a thread in the future about this.

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.

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

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)