Bitcoin Forum

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

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

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

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

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?

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;

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

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

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

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

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


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…

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?

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.

Later when the game is complete I would publish the seed

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

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.

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

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.


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.

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

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

Argh, what an awful moment to get an "Keypool ran out, please call keypoolrefill first" error, just when this thread receives a free bump! :D. The immediate internet search turned an answer here (http://bitcoin.stackexchange.com/questions/4095/how-does-bitcoind-generate-a-new-address-if-the-wallet-is-encrypted). Man, you're useful!

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

I increased the size of the address box to 50 chars.

I just won a game but wasn't paid out.  The payment transaction is "oops..." :)

$ bitcoind getbalance
0.34425772

Hey this provable fairness stuff isn't actually fair! I was expected to earn coins with this, not lose them! :D

I'm sending some funds to the wallet as I type this.

Are you aware that the FlipSide web page is down?

I get a "HTTP/1.1 503 Service Temporarily Unavailable" error.

Hey this provable fairness stuff isn't actually fair! I was expected to earn coins with this, not lose them! :D


I'm sending some funds to the wallet as I type this.

Edit: done!