The "foo or bar ?" game

[grondilu]

Here is a game I invented.  It's called "foo or bar ?".  You have 50% chance of winning (it's just like "heads or tail ?" game but "foo or bar ?" is funnier a title).

You play for bitcoins.  I'm ok to play for 0.01 BTC.  If you win, I'll pay you 0.01 BTC.  If I win, I expect you to pay me 0.01 BTC.  If I win and you don't pay, I won't play with you anymore.  Fair enough, right ?

Here is how it works.  I mentally choose between "foo or bar", and I write on my PC a string such as :

foo SOMERUBBISHDATAIWRITEONMYKEYBOARD,flnkjkjngf,lf,kze,dlk,ze,dlk,efle,fl

Then I compute the sha256sum of this string.

I show you this hash, and I ask you "foo or bar ?"

If you guess right I pay you, if you're wrong I prove it to you by showing you the inital string.


Here it is :

43991dbe755b2dbec0b2a5094614c2d7ced35ca0250e3304fbda552e

So,  foo or bar ?

[1713529600]

1713529600

[bitcoinex]

Automatic version: http://bitcoindarts.movoda.net/

[grondilu]

Automatic version: http://bitcoindarts.movoda.net/

Ahh indeed !  I feel stupid suddenly

Edit.  Hang on :

When your payment is received the information in it will be used to generate a hash and the last 4 digits (in hex) of that number will correspond to x and y coordinates on the dartboard shown below.

That's not very clear.  How can I check that x and y was fairly generated ?

Anyway I give it a try.  I want to see how it works exactly.

400 Bad Request.

pff...  0.01 bc lost  without even playing 

Unless that was the real game

edit.
Ah ok I could use my browser history to go back to my game.

I won this one.

edit.

Ok I've lost one.  Here is the message I've got :

Your dart landed in the Off the Board section which pays 0% back.

The payment hash that was used was d3a57c81bda9082954aa54d566b6c994f9764ed86ed3c5bc7d39ca830f17fdd3

How am I supposed to check that this was fair ??

[LZ]

I think you may ask the author to explain it.

I recently intentionally lost about 1,000 BTC playing darts. Is someone ready to win it?

[mskwik]

I was directed here by someone asking questions about the darts game and after looking it over I have adjusted the game to calculate the winning hash ahead of time (in the same random fashion as before) and along with the address to send the bet to it will show the hash of the winning hash for that transaction, so that after the transaction is complete and the winning hash is revealed you can (if you want to, no extra requirements to play) check that it matches.

Still doesn't necessarily give any verification of the randomness of the hashes generated, but should be enough to show that the outcome isn't dependent on the size of the bet without revealing bet sizes in the history.

[grondilu]

I was directed here by someone asking questions about the darts game and after looking it over I have adjusted the game to calculate the winning hash ahead of time (in the same random fashion as before) and along with the address to send the bet to it will show the hash of the winning hash for that transaction, so that after the transaction is complete and the winning hash is revealed you can (if you want to, no extra requirements to play) check that it matches.

Still doesn't necessarily give any verification of the randomness of the hashes generated, but should be enough to show that the outcome isn't dependent on the size of the bet without revealing bet sizes in the history.

I'll try that, thks.  Indeed if you don't show the hash before the player bets, there's nothing preventing you from chosing a losing outcome after the player has bet.

Edit.
I've tried again, and I still don't understand.  Sure, it gives me a hash before I send money.  But that doesn't prove anything.  It doesn't even tell what hash function has been used.  It doesn't prevent you from chosing the lose/win ratio you want.

Edit #2.

Here is what I suggest.

First, you chose a random string and you keep it secret for now.  Let's call it $s

You then show the sha256sum of this string.

Code:

$ sha256sum <<< "$s"

Then you ask the player for an integer $n.  Once the player has given you this number,
you can show him $s, and everything that you will do next doesn't have to be secret.

You compute n successive hashes of $s.  You have to use a different hashfunction that the one used previously, otherwise the player could chose $n in order to obtain a winning outcome.  So let's use sha224 here instead of sha256.

Code:

$ f() { sha224sum <<< "$1" |cut -d' ' -f1; }  
$ while ((n--)); do h=$(f "$h"); done

Once this is done, you compute two more hashes, and you build your two coordinates with them :

Code:

$ x=$(f h); y=$(f x)
$ x=0.${x//[a-f]/}
$ y=0.${y//[a-f]/}

Finally you can use those coordinates for your dart game.

[mskwik]

Yeah, as I state there it doesn't necessarily prove anything about the output randomness, it just proves that the outcome is the same regardless of the bet amount.  The hashes are all sha256 (since that seemed to fit in nicely with what bitcoin is based on), suppose it probably should say that somewhere.

I do see what you're saying, biggest issue with that sort of thing is that it adds to the complexity for everyone playing when most people aren't going to worry about checking the results every time.  I suppose it could be setup to be optional, have a set default and accept payment anytime after the address is given but also allow some user input that will verifiably change the result as long as it is received before the payment.  Even just a user specified coordinate offset with the way it works now would have the same effect.

[grondilu]

I do see what you're saying, biggest issue with that sort of thing is that it adds to the complexity for everyone playing when most people aren't going to worry about checking the results every time.  I suppose it could be setup to be optional, have a set default and accept payment anytime after the address is given but also allow some user input that will verifiably change the result as long as it is received before the payment.  Even just a user specified coordinate offset with the way it works now would have the same effect.

Well, this enters the category of "mental poker" games, and thus it is indeed a bit complex.  But complexity is a price to pay if you want your website to be a fair game place.

I'd also have a few things to say about when exactly should the paiement occur.  I'll talk about that later.

Also, if someday I can manage to have my website working again on freeshell.org, I may implement an prototype of a fair playing roulette game.

I don't bet nor gamble.  I don't like this kind of activities, but I'm surely interested in the "mental poker" problem, from a purely technical aspect.

[mskwik]

Well, this enters the category of "mental poker" games, and thus it is indeed a bit complex.  But complexity is a price to pay if you want your website to be a fair game place.

Not necessarily, I know that it's perfectly fair the way it is working right now.  What's under discussion here is more a way of offering proof of that...

Was never really intended to be more than a "here try this out" type of thing, it kind of looses that aspect if you need to follow what it is actually doing to play.  I can certainly appreciate that some people will read everything and check the calculations themselves and so on, I would fit in that same category myself, but I also understand that some people will just want to throw a small amount at it and see what happens.

[macje6645]

It is really interesting how games like this take off.  It seems that people will get entertained by so many various item.  That is how you can see them selling over a million game apps on iTunes.  People love stuff like this.  Keep up the great work.