Topic: bitZino - Bitcoin Casino - Blackjack, Roulette, 3 Card Poker, Slots and more! - page 11. (Read 82361 times)

You guys happen to be down at the moment?
Created an account, played for about 30min, now unable to load the page.
Am able to Ping and TraceRoute the site.

You guys happen to be down at the moment?
Created an account, played for about 30min, now unable to load the page.
Am able to Ping and TraceRoute the site.

Any comments on this, libertaad:

http://www.reddit.com/r/Bitcoin/comments/1frm4x/provably_fair_by_bitzino_not_provable_with/

Creator of bitZino here. Thanks for writing this post, TrevorXavier! I firmly believe that the best cryptography is that which is practiced in the open, with honest and open discussion about any possible weaknesses or avenues of attack.

I've read through your entire post, and I believe that at the core, you are discussing two main issues you see with our provably fair system:

The first issue is that of "stalling". In the rare event that our servers do fail to respond (either due to internet connectivity issues, or downtime on our end), this problem can easily be mitigated by a player by simply ensuring the `Hash(secret)` has not changed, and then re-entering the same `client_seed` after reloading the page.

The second issue is that of tainting the javascript that is being executed on the player's browser (Cold Deck, Hot Reading, Mutation, and Controlled Secret all fall under this). I do agree that if we managed to slip dirty code past our users, these are potentially viable attacks. However. these are all very high-risk frauds to perpetrate, because if we were caught doing this, even once, we would completely sacrifice our reputation and future earnings potential.

Furthermore, these attacks are all relatively easy for a savvy user to detect. Since modern browsers come with built-in network analysis tools, it is easy for anyone to see all data being sent down the wire. These tools would make it very easy to detect if we tried to sneak javascript partials into ajax requests.

Ultimately though, a player can be protected from all of these attacks by running a client-side greasemonkey script which generates the client_seed (rather than relying on any code sent from our servers). And, in fact, this is already possible today due to the nature of our app being in HTML5. We have already seen a handful of our players doing this on their own (we can detect it because the client_seeds they send are formatted differently than the ones our javascript generates). Additionally, if a player just edits the client_seed by hand before they play, they are also protected from any of the attacks you listed.

At the end of the day, we still haven't fully solved the trust issue of browser-based cryptography. But, our system still accomplishes its goal - it forces us to either be honest, or take a large risk. We simply have no way to manipulate the outcome of any wagers made on bitZino without taking a risk of being caught. That's why our system is indeed provably fair: it allows savvy players to ensure the house isn't cheating them.

Thanks again for the insightful post!

Any comments on this, libertaad:

http://www.reddit.com/r/Bitcoin/comments/1frm4x/provably_fair_by_bitzino_not_provable_with/

Thank you for reaching out to us! I am sorry for the problems you have experienced while playing at bitZino. I am also sorry for the delay in getting back to you.

I have take a look into your craps gameplay from the last 12 hours, and I believe I see what happened. I have also attached a log of all your craps gameplay for the pat 12 hours, so you can take a look yourself as well.

Looking at your craps gameplay logs, it looks like the gameplay between 14:46:44 and 14:53:39 are the games you are talking about. You cashed in for 500, and then worked it up to nearly 1000, and then cashed out. However, it looks like these games were all for μ฿, not m฿. This means that when you cashed in 500, you were only cashing in 0.0005 BTC, rather than 0.5 BTC. Then, when you cashed out, you were only cashing out 0.001 BTC, rather than 1 BTC.

I am sorry for your confusion in this matter! I have decided to just go in and comp you with a 0.5 BTC bonus in order to make up for the confusion, and make it as if you were actually playing for m฿, since it is clear that this is usually what you play at.

As a reminder for the future, you can always see what stakes you are playing at by referring to the lower-left corner of the table.

Please let me know if you have any more questions or concerns, and thanks for playing at bitZino!

Could it be that the advantage to the player of having hands rich in high cards is less than the advantage to the dealer of having a deck rich in low cards? 

Ok, I think I found some good reasoning that actually makes sense! I kept reading the thread on the bjmath.com site, and the exact question is answered:

To get to those potential extra hands, though, the initial hands in the shoe would have been advantageous.  If, on average a shoe gives a full table say, 6 hands, then a table that reaches the 8th hand most likely had more advantageous cards during the hands that came before it.  There was just no way of knowing it at the time.  I think it is accurate to say that there is no known advantage at the beginning of a shoe.  But, without counting cards (but counting hands), one can assume that an 8th, 9th, 10th, etc. hand at a table that averages 6/shoe is less advantageous than an average first hand.  But it is so only because the initial hands were more advantageous.

That is right. But those three rounds that are rich in 10s are already reflected in the Basic Strategy (no cut-card) EV. That is, without a cut-card we are going to some rounds which are rich in 10s, and some which are lean. The average of all of these is reflected in the BS expectation.

Here is a though experiment which may help clarify. Imagine two players Me (M) and my Shadow(S) betting on the same spot. S is basically making "over-the-shoulder" bets on my box. The hands are played in accordance with BS and we both must put up more money when we split and double.

Suppose the games is dealt with the cut-card listed above. M flat-bets on all the rounds. S bets the same on the first three rounds, but never plays a 4th round. Now S's EV should be that of Basic Strategy (full-deck). My EV is clearly less than S. The only difference between us is the money I lose on those negative 4th rounds. So M is worse off with the cut-card.

Now when there is a 4th round, the first 3 rounds are favorable to M. But they are also favorable to S. S gets all the benefits of those, but doesn't actually bet the negative 4th round.

but the bad hand or two at the end seems like it wouldn't negate the advantage from all the good hands the player saw in the rest of the shoe.

I also like their chart. It shows that the earlier hands will have the same odds regardless, the difference in odds comes later on, in the extra hands that are being played as a result of the earlier good hands.

Where am I going wrong here?

If there's a cut-card 70% of the way through the deck, 30% of cards are unplayed.

If those unplayed cards are rich in low cards:
 * the played cards are rich in high cards
 * so hands use relatively few cards (players don't hit much)
 * so relatively many hands are played per shoe
 * and players do well (high cards are good for player)

Conversely, if the unplayed cards are rich in high cards:
 * the played cards are rich in low cards
 * so hands use relatively many cards (players hit more with low cards)
 * so relatively few hands are played per shoe
 * and players do badly (low cards are bad for player)

So the players with see many good hands, or few bad hands per shoe.

That sounds like on average players will do better with a cut-card than if you shuffle every hand, since they'll see more good than bad hands.

The wizard's simulation shows exactly the opposite to be true.  So where am I going wrong here?

In this set of circumstances, if you deal to a cut card you may get five, six or seven rounds depending on the cards. This is because the player and dealer can have hands of two cards or many cards. If there are many high cards (e.g. tens) dealt, we will end up with two- and three-card hands. If there are small cards dealt, we will end up with hands with many cards. So, if we are dealing to a fixed point, and we are dealt a lot of large cards, then we will use fewer cards per round and get an extra round or two. The problem is that these extra rounds will be dealt from a deck with fewer high cards because they have been used up. And we know that a deck with few high cards left is bad for the player.

I can't agree with that statement.  When playing through to a cut-card, the player gets into this situation if the cards near the cut-card are rich in small cards.  That's just as likely to be the case as the top of the deck being rich in small cards.  The only difference is that when playing through the shoe the player can count the number of hands he's played, and if it's too high he can know that he's in a bad situation, and so he can lower his bet accordingly, or walk away.  When playing with a freshly shuffled deck he's just as likely to be in this bad low-card situation, but has no way of knowing it.

So, by reshuffling the deck before every hand, there is no chance that the player winds up in a situation where the show is unfavorable because it is rich in small cards.

However if the dealer deals out much more than the average number of hands in a cut card game the last hands tend to be very bad for the player. This is because in the early hands the players and dealer didn't hit much, which in turn is because lots of large cards came out, leaving more small cards for later in the shoe.

Short answer: our blackjack game uses 8 standard 52-card decks which are reshuffled before every hand.

Long answer: Every single blackjack hand played on bitZino is a fresh set of 8 decks of cards (each of the 8 decks are standard 52-card decks, thus making a blackjack deck contain 416 cards). Before each hand a fresh blackjack deck (containing 416 cards) is shuffled on bitZino's servers using a cryptographically secure random number generator. The hash of this "initial_shuffle" is then presented to you, and your browser are also asked to generate a random "client_seed" (you are also free to manually modify this client_seed). BitZino's servers then reshuffle the deck using the client_seed provided by you as the source of randomness.

This reshuffling process is what allows the game to truly be provably fair. Since our servers have no knowledge of the client_seed until the exact moment the game is starting, it is impossible for us to manipulate the outcome of any games, without making it obvious that we've done so.

I'm happy to answer any more questions about our provably fair process! We also wrote up a detailed technical blog post if you really want to get into the nitty-gritty details: https://techblog.bitzino.com/2012-06-30-provably-fair-shuffling-through-cryptography.html

Just ask a dealer next time you're at the casino.  Ask them if the dealer wins the majority of the first hand dealt from a new shoe.  I don't know why this is, it's just the way it is.  I always bet the minimum on the first hand when playing live. 

Big card follows little card. Little card follows big card. Dealer wins first hand x% of the time, usually between 80% and 90 - yes dealers are ploppys too. Lower your bet when the relief dealer burns a card. Surrender? You may as well mail in a check. I'm due for a win. Quit when you're ahead. Never split anything that starts with the letter f. Always take even money it's a sure win. Drop/add a hand to change the cards. You'll win more if you tip.

There's no logical reason to expect the first hand of the shoe to
play out any differently from any other hand.