Topic: FlipSide - Prizes almost 5 million times your bet! (Read 5036 times)

What a great game!

Had two goes at it. 1 win and 1 Loss but fun nethertheless. Congrats on making such a fun game and best of luck hope it takes off for you

This looks pretty cool. I haven't tried it out myself but I see this being a really fun game.

Good luck on it. I plan to try this out shortly. Keep developing games! Don't stop.

Nice original game!

BTW, would you mind adding a table with the odds involved in the game on that site?

Cheers!

Thanks for the reports, I wasn't aware. It's up again now.

I get *Internal server error*.

Are you aware that the FlipSide web page is down?

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

It doesn't make the games fair, it just stops cheating.  You could offer 30x payout for any single number on roulette and make it "provably fair", but it wouldn't be fair - the players would end up losing.  All it would prove is that you were spinning the wheel fairly.


Received, thanks.

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


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

Edit: done!

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




That's fine now.  There's room to spare, but I guess that depends on the address:



I'm using Chromium "Version 25.0.1364.160 Ubuntu 12.10 (25.0.1364.160-0ubuntu0.12.10.1)" if you care.

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

The bet limits are calculated when a game is created and are attached to that specific game, so if you:

• Create a game, leave it in the background.
• Play some other games, altering the wallet's balance.
• Return to the backgrounded game and reload it.

The limits of that game shouldn't have changed.

The worst case scenario is that by playing many winning games in between, the wallet balance could decrease up to a point that when the original game is also won, there could be not enough balance left. I would have to manually fund it in this case.

Sorry to keep bumping your thread, but it just occurred to me:

a) There seems to be no limit to the number of games I can have 'in progress' at a time.  Earlier I played 30 games in a single transaction, sending bets to 30 different addresses that your site sent me.

b) It looks like you adjust the max bets according to how your wallet balance is doing.

Do a) and b) conflict with each other?  Do you adjust the max bet after each game, even if you already told the player a different max bet?  I guess you can't, really, or it's an avenue for you to cheat the player.  "Sorry, you would have won, but it turns out your bet was over the maximum bet because we just reduced it".  Although I believe that's what SatoshiDice does - they change their max bet with no notice.

The 7-7 game shows a minimum bet of zero:

That's funny.  I'm the #1 google search result for all your problems. 

The box still isn't big enough for my address (showing that I see '40' in the source, but the address still doesn't fit):



Also, I keep winning.  I played 9 times today (6 cards, A-A) and won every time!



I wrote a little Perl script that checks the provable-fairness, and that's working just fine:


The script is pretty bad - I've forgotten most of the Perl I ever knew, so I'm using backticks to invoke subshells, etc.  But it does the job:

Note that you don't have to have enough coins in the hot wallet to be able to pay out all winning bets.  If someone wins 5 million times their bet I'm sure they'll be happy to wait 24 hours for you to get their winnings online.

Check out bitmillions.com for instance.  They keep their two biggest prize pools offline since they are very rarely won.  So long as your code can handle the case of your hot wallet having insufficient funds, you'll be OK.

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 .



Best of luck!

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

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.

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.

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


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.