FlipSide - Prizes almost 5 million times your bet!

[dserrano5]

Last year I was on medical leave and coded a little bitcoin game (just for fun, won't be big and professional like sd). When development was almost complete I began to work again and the code remained collecting dust in the server.  I just cleaned it up and tested it, and I think it's ready for public usage .

In a nutshell, users are shown a set of cards and are invited to pick some of them, then place a bet. When the bet transaction is included in a block, some other cards are derived from the block hash and compared with the ones picked by the user. If all of the user's cards are equal or higher, she wins. The help within the game gives all the details.

This is an example of a completed game, which shows the user-chosen cards as well as the ones derived from the block hash. There's a tie in one of the cards (an ace of diamonds). The user won this game.

A SHA386 hash can also be seen above the set of cards. This can be used to prove that the game doesn't cheat.

If the design is awful, sorry, I'm not a web designer .

You can give it a try at https://dserrano5.es/btc/flipside (HTTPS only).

[silvergoldandbitcoin]

Hello! Interesting game! If there is a tie in the cards, isn't the player supposed to win?

This was the game I played:

https://dserrano5.es/btc/flipside/game_id/87b0bae4c86baa59

[dooglus]

Hello! Interesting game! If there is a tie in the cards, isn't the player supposed to win?

I think so, but:

The order of suits is clubs < diamonds < hearts < spades.

[dooglus]

In a nutshell, users are shown a set of cards and are invited to pick some of them

How is the set of cards selected?  From a 'provable fairness' point of view can you prove that the card selection isn't skewed towards the lower cards?

[dserrano5]

Hello! Interesting game! If there is a tie in the cards, isn't the player supposed to win?

Thanks for trying! As dooglus noted, that wasn't actually a tie since the kings were of different suit.

How is the set of cards selected?  From a 'provable fairness' point of view can you prove that the card selection isn't skewed towards the lower cards?

Ah, this detailed escaped me. They are randomly chosen using the "shuffle" method from the builtin Perl module:

Code:

my @deck;
do {
    push @deck, grep { $_->{'value'} >= $min_bits and $_->{'value'} <= $max_bits } (@btc_deck)x$MAX_CARDS;
} while @deck < $CARDS_TO_DISPLAY;
my @ret = shuffle @deck;

But this post doesn't prove anything, of course. I'll have to figure something out. Seems I'll have to resort to the (IMO) inelegant list of pre-generated secrets…

[MPOE-PR]

So if I can afford to bet twenty bitcoin you can afford to pay out 10x the BTC M3?

[John (John K.)]

So if I can afford to bet twenty bitcoin you can afford to pay out 10x the BTC M3?

Code:

Minimum bet: 0.00000000 BTC.
Maximum bet: 0.00000025 BTC.
Prize: 4890000x.

[GoWest]

So if I can afford to bet twenty bitcoin you can afford to pay out 10x the BTC M3?

Seriously dude, you're a smart guy, but why do you ask questions like this? Do you really think the developer didn't consider the math before determining bet limits?

[haitispaceagency]

If all of the user's cards are equal or higher, she wins.

really want to play this buy I have a penis

[dooglus]

Ah, this detailed escaped me. They are randomly chosen using the "shuffle" method from the builtin Perl module:

Code:

my @deck;
do {
    push @deck, grep { $_->{'value'} >= $min_bits and $_->{'value'} <= $max_bits } (@btc_deck)x$MAX_CARDS;
} while @deck < $CARDS_TO_DISPLAY;
my @ret = shuffle @deck;

But this post doesn't prove anything, of course. I'll have to figure something out. Seems I'll have to resort to the (IMO) inelegant list of pre-generated secrets…

What's $MAX_CARDS? 6?  So you're selecting the 50 cards from 6 decks of 32 cards?

The way this is usually done is to shuffle the decks using a seed derived by combining the site secret and the client secret (the block hash, in this case).  So you can prove that you had no control over the selection of the 50 cards.

Even if you pre-generate the sets of 50 cards, you still can't prove that they were fairly selected.  You could still pick more 7's than Aces.

Edit: $MAX_CARDS can't be 6, or you would only have 24 sevens, and you wouldn't be able to deal 50 sevens for the jackpot game...

Edit2: Oh, but you're running the grep in a loop until you have enough, so that's OK.

[MPOE-PR]

So if I can afford to bet twenty bitcoin you can afford to pay out 10x the BTC M3?

Seriously dude, you're a smart guy, but why do you ask questions like this? Do you really think the developer didn't consider the math before determining bet limits?

I am a gal, and I was making a point.

[dserrano5]

What's $MAX_CARDS? 6?  So you're selecting the 50 cards from 6 decks of 32 cards?

Yes. Initially 32 cards were shown but at some later point I decided to make a better usage of the screen real state and upped it to 50. (And earlier than that, my original plan was to always show all cards between 7-clubs to ace-spaces once, like when using a real deck).

The way this is usually done is to shuffle the decks using a seed derived by combining the site secret and the client secret (the block hash, in this case).  So you can prove that you had no control over the selection of the 50 cards.

Thanks for this insight. The client secret could perfectly be the game ID (randomly generated but trivially editable by the user). The server side has to be the pre-generated secret I alluded to.

Even if you pre-generate the sets of 50 cards, you still can't prove that they were fairly selected.  You could still pick more 7's than Aces.

I can use a known PRNG (e.g. ISAAC, which has a readily available Perl implementation) with a given seed to generate the cards, and publish a hash of the seed. The seed would be created from the client and server secrets. Later when the game is complete I would publish the seed and give the details of the card generation.

[dserrano5]

Later when the game is complete I would publish the seed

Ah, when the game is complete and the server secret is no longer valid, of course!

[dooglus]

I decided to make a better usage of the screen real state and upped it to 50.

That reminds me.  If I don't have the browser window full-width then the 'flip side' text down the left hand edge of the screen goes underneath the 50 face down cards, but when I try to click on the cards in the first column, it thinks I'm clicking on the 'flip side' text, and takes me to a new page, rather than toggling the selection state of the card I clicked on.  Took me a while to figure out what was wrong, but until I did it was very confusing.

Thanks for this insight. The client secret could perfectly be the game ID (randomly generated but trivially editable by the user). The server side has to be the pre-generated secret I alluded to.

Just make sure that it goes in this order:

1. show hash of server secret to user
2. allow user to select their secret
3. shuffle cards using server secret and client secret

If you do 2. before 1. then you could be selecting a server secret that makes the client secret bad for the user.  Doing 1 before 2 is required if we're to know the game is fair.  When you do it that way, we don't care how you pick the server secret, and so there's no need to pre-generate anything.  Just pick a pseudorandom server secret, show us its hash, allow us to pick our own secret, then use both as the seed for all in-game randomness.

You don't even need to use external sources of randomness like the block hash then.  We don't know the server secret, so can't cheat.  And you don't know what secret the client is going to pick, so you can't cheat either.

Neat, huh?

[dserrano5]

1. show hash of server secret to user
2. allow user to select their secret
3. shuffle cards using server secret and client secret

Thanks dooglus for your input. I've made the necessary changes and put the new code online. This is a finished game with the improved provability. I entered a user secret containing the Euro symbol to show that there's an issue with the encoding; however, the sha384sum is correct. Help has been updated accordingly too.

Another example shows that when the RNG generates out-of-range cards they are skipped (lower than J-clubs in this case). It still amazes me that betting 0.73 BTC is now a whopping 80 euro…

Please get yourself a pizza for both your help here and this stackexchange post that was useful for my coin control utility .

[dooglus]

I PM'ed the game's owner with the following a few days ago.  Since he's fixed the issues now I figured I'd post it here to show how you have to be careful when implementing 'provable fairness'.

Hi.

I was going to post this in the thread but then realised that it would expose you to people exploiting the issues I mention, so I'm PMing you instead.

Please get yourself a pizza for both your help here and this stackexchange post that was useful for my coin control utility .

Hey thanks!  I was wondering where that 0.1 BTC came from.    I somehow missed your post here.  The forum's "watchlist" feature is a little buggy I think.

A few comments on your new provably fair system:

1) You only publish the first 4 bytes of the server secret's hash.  You could have pre-selected a bunch of server secrets with known collisions in their first 4 bytes.  That's not hard to find.  Then when you see the client secret and the block hash you can pick which of the pair (or more) of server secrets is best for you.  It would be better if you published the whole hash of the server secret to remove this as a way of you cheating.

2) The server secret is only 4 bytes long.  There are only 4 billion possible server secrets.  It wouldn't take very long with decent hardware for me to brute force it.  If I'm lucky there's only one server secret that hashes to the right value.  I can test it against multiple client secrets until I find one with 6 of the best card, and pick those 6.  You should use longer server secrets so players can't brute force them.  I don't know how slow sha386 is compared to sha256, but people regularly run 1Ghash/s when mining.  That would mean they can find your secrets in 4 seconds.  You don't need to use the whole secret in the concatenation that seeds ISAAC - you can safely use just the first 4 bytes - but tack some random junk on the end to make it impossible to discover up front.

3) I wasn't able to figure out how to seed the C version of the ISAAC RNG you linked to.  But package libmath-random-isaac-perl in ubuntu worked fine, and reproduces your numbers.

Chris.

[dooglus]

A slightly less important bug:

The "Payout address:" box isn't wide enough for me to see the whole address.  I tend to check the first few and last few characters to see that the address is right, but can't see the last few very easily.

[dserrano5]

Argh, what an awful moment to get an "Keypool ran out, please call keypoolrefill first" error, just when this thread receives a free bump! . The immediate internet search turned an answer here. Man, you're useful!

I just increased the box size from 35 to 40, which should be more than enough.

[Zaih]

5 million times your bet?? Bloody hell lol! You couldn't help feel sorry for ya if you lost one of those bets haha.

Your game looks cool though. I'll give it a whirl when I get home

[dserrano5]

5 million times your bet?? Bloody hell lol! You couldn't help feel sorry for ya if you lost one of those bets haha.

Well with the upcoming limitation of small outputs I guess betting to those games will become somewhat difficult—unless I fill the hot wallet with 300 coins .

Your game looks cool though. I'll give it a whirl when I get home

Best of luck!