Pages:
Author

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

newbie
Activity: 55
Merit: 0
Well I think I'm finally calling it quits after all these months losing so much.  The final straw is when he hits 4 BJ's in a row then a 20 then a dealt out 21 and 2 more BJ in a row.  I have never seen something like that in real life...
So can anyone explain this to me ?  How is it possible or getting red or black 18 times in a row ?  The odds would have to be astronomical...


If you play enough hands, crazy shit like this will happen sometimes. I have a screen shot from Bitzino when I was dealt 6 aces in a row on blackjack. I couldn't even split anymore!

These situations are so unusual that you remember them more than the thousands of boring hands in between.

There have probably been times where you got 4 blackjacks in a row, also. These crazy streaks are all part of the gamble.

Yea you're right, i just lost a few hundred bucks and was mad.  But what you say is true, I have streaked before on multiple occasions.  Learning to stop when ahead is my problem lol.
newbie
Activity: 53
Merit: 0
I don't see how adding a nonce helps.  If I can find two "random" strings with the same hash, I can surely also find two random strings which both begin the same nonce which also have the same hash.  You're not reducing the search space by specifying that both strings must have the same prefix.

Collision attacks are much less expensive than hash cracking. Crafting during months two unconstrained seeds with equal hash is more feasible than making them both fit a nonce that is changing every 10 minutes or so.

However, I concede that neither case is provably fair once collisions are possible. It is only about strengthening the system with collisions.
sr. member
Activity: 449
Merit: 250
Well I think I'm finally calling it quits after all these months losing so much.  The final straw is when he hits 4 BJ's in a row then a 20 then a dealt out 21 and 2 more BJ in a row.  I have never seen something like that in real life...
So can anyone explain this to me ?  How is it possible or getting red or black 18 times in a row ?  The odds would have to be astronomical...


If you play enough hands, crazy shit like this will happen sometimes. I have a screen shot from Bitzino when I was dealt 6 aces in a row on blackjack. I couldn't even split anymore!

These situations are so unusual that you remember them more than the thousands of boring hands in between.

There have probably been times where you got 4 blackjacks in a row, also. These crazy streaks are all part of the gamble.
newbie
Activity: 7
Merit: 0
well , all this talk on bitzino. I will give it shot, I will update everyone on the status. My roommate lost al his coins, but felt that it was overall a pretty good site. I know he taped it, and from what I saw other then the freeze ups, seems to be pretty legit. I'll give it a go. wish me luck!
newbie
Activity: 55
Merit: 0
Well I think I'm finally calling it quits after all these months losing so much.  The final straw is when he hits 4 BJ's in a row then a 20 then a dealt out 21 and 2 more BJ in a row.  I have never seen something like that in real life...
So can anyone explain this to me ?  How is it possible or getting red or black 18 times in a row ?  The odds would have to be astronomical...
sr. member
Activity: 266
Merit: 252
Adding a nonce, as I propose, would make the system remain provably fair even in that case.

I agree with Dooglus that adding a nonce doesn't seem to make it any harder for a malicious actor find collisions. The key to being resilient against collisions is choosing a good hash algorithm like SHA2.

Alternatively,  let us assume a game scaled-down to only 12 cards: it is reasonable to expect that you could repeat a previously seen permutation and be abused by a malicious player. Adding a nonce would prevent cheating also in that case.

We protect ourselves from this scenario by adding a random server_seed to the Secret component. So, even for a game with a small deck of cards, the Secret will always be different because we'll choose a different server_seed for every shuffle.
sr. member
Activity: 602
Merit: 260
Finding collisions on SHA-2 would not kill bitcoin if developers react in time. However, malicious dice would be able to cheat. Adding a nonce, as I propose, would make the system remain provably fair even in that case.

A malicious dice site wouldn't have chosen SHA-2 as their hashing algorithm if the way they're cheating is by using colliding server seeds.  They'd be using a hash function with known collisions.

As soon as SHA-2 is found to have an exploit, Bitcoin mining and reputable gambling sites will no doubt start using SHA-3 (or whatever becomes the new standard).

I don't see how adding a nonce helps.  If I can find two "random" strings with the same hash, I can surely also find two random strings which both begin the same nonce which also have the same hash.  You're not reducing the search space by specifying that both strings must have the same prefix.

Dooglus, how do you create them win/loss/net line graphs?
legendary
Activity: 2940
Merit: 1333
Finding collisions on SHA-2 would not kill bitcoin if developers react in time. However, malicious dice would be able to cheat. Adding a nonce, as I propose, would make the system remain provably fair even in that case.

A malicious dice site wouldn't have chosen SHA-2 as their hashing algorithm if the way they're cheating is by using colliding server seeds.  They'd be using a hash function with known collisions.

As soon as SHA-2 is found to have an exploit, Bitcoin mining and reputable gambling sites will no doubt start using SHA-3 (or whatever becomes the new standard).

I don't see how adding a nonce helps.  If I can find two "random" strings with the same hash, I can surely also find two random strings which both begin the same nonce which also have the same hash.  You're not reducing the search space by specifying that both strings must have the same prefix.
newbie
Activity: 55
Merit: 0
Well I think I'm finally calling it quits after all these months losing so much.  The final straw is when he hits 4 BJ's in a row then a 20 then a dealt out 21 and 2 more BJ in a row.  I have never seen something like that in real life...
newbie
Activity: 53
Merit: 0
I have a question on how the provably fair system can resist collision scams.

I know this would be extremely difficult in the bitZino case (impossible for all practical purposes as long as the hashing algorithm remains unbroken), because the server secret is a coherent JSON string of cards. However, this could be the case on a cointoss setup where the server secret seed is just a random (or random-looking) string.

A malicious server could select two colliding seeds and show their identical hash. Then, upon receiving the client seed, the server chooses the server seed that yields the most favorable outcome and reveals it to the client, who has no means to know about the existence of the alternate seed. Therefore, the system is not provably fair.
Know collisions exist for the still widely used MD5 algorithm, and theoretical collisions (a significant reduction of the entire search space) are possible for SHA-1.

A possible solution could be that in the first step, the server combines its secret seed with a public nonce and shows the combined hash. This ensures that no collisions are available.

What do you think?

Thanks for the question oriolpont! bitZino uses the SHA256 hashing algorithm in our provably fair process, so our users are not susceptible to a hash collision attack as you describe. The SHA256 hash algorithm is the same one used for bitcoin mining, so if hash collisions in SHA256 become possible at some point in the future, we'll have a much larger problem on our hands than just bitZino's provably fair system.

Thank you, at least someone told the truth about it.  I was trying to say this for a long time and no one would listen lol.  Also they can effect the odds without you evening know and still show the correct hash. This dont mean anything with the provable fair system.

We cannot influence the odds of any wagers you place in bitZino, other than simply changing the rules to the game in question, which you will know (for example, if we paid out 6 to 5 on a blackjack instead of 3 to 2, you'd be able to easily notice this).

I posted this here because I noticed that bitzino is very pedagogical on the concept of provable fairness, and the subject is being actively discussed here.

Thank you for posting this, and feel free to follow-up if I wasn't clear enough in my explanations! Also, in case you didn't know, we wrote up a detailed article about the technical aspects of our provably fair system. You can read it here: https://techblog.bitzino.com/2012-06-30-provably-fair-shuffling-through-cryptography.html

Thanks for you answer, libertaad. Yes, I have seen the report and at least got its bases. You are a major advocate of provable fairness, so I would appreciate that you consider the broader system independent of the bitzino implementation. Let us say that order-based server seeds are not collidable (intuition but not proof). Still, many gambling dice use random-looking seeds, which could allow collusions once they are found (we shifted to SHA-2 from SHA-1, and to SHA-1 from SHA-0, and to SHA-0 from MD5, when collisions were found on them).

Finding collisions on SHA-2 would not kill bitcoin if developers react in time. However, malicious dice would be able to cheat. Adding a nonce, as I propose, would make the system remain provably fair even in that case. Alternatively,  let us assume a game scaled-down to only 12 cards: it is reasonable to expect that you could repeat a previously seen permutation and be abused by a malicious player. Adding a nonce would prevent cheating also in that case.
sr. member
Activity: 449
Merit: 250
Glad to see you back, libertaad! It's been strange with you being absent from the forums for so long!
sr. member
Activity: 266
Merit: 252
We have played around 100,000 hands of blackjack at Bitzino over the passed 6 months with success. Is there anyway to get a hand history so we can break this down in a chart?

regards
alan

We're happy to provide you a hand history! Please just reach out to our support team (https://bitzino.com/support), and they'll take care of you.
sr. member
Activity: 602
Merit: 260
I have a question on how the provably fair system can resist collision scams.

I know this would be extremely difficult in the bitZino case (impossible for all practical purposes as long as the hashing algorithm remains unbroken), because the server secret is a coherent JSON string of cards. However, this could be the case on a cointoss setup where the server secret seed is just a random (or random-looking) string.

A malicious server could select two colliding seeds and show their identical hash. Then, upon receiving the client seed, the server chooses the server seed that yields the most favorable outcome and reveals it to the client, who has no means to know about the existence of the alternate seed. Therefore, the system is not provably fair.
Know collisions exist for the still widely used MD5 algorithm, and theoretical collisions (a significant reduction of the entire search space) are possible for SHA-1.

A possible solution could be that in the first step, the server combines its secret seed with a public nonce and shows the combined hash. This ensures that no collisions are available.

What do you think?

Thanks for the question oriolpont! bitZino uses the SHA256 hashing algorithm in our provably fair process, so our users are not susceptible to a hash collision attack as you describe. The SHA256 hash algorithm is the same one used for bitcoin mining, so if hash collisions in SHA256 become possible at some point in the future, we'll have a much larger problem on our hands than just bitZino's provably fair system.

Thank you, at least someone told the truth about it.  I was trying to say this for a long time and no one would listen lol.  Also they can effect the odds without you evening know and still show the correct hash. This dont mean anything with the provable fair system.

We cannot influence the odds of any wagers you place in bitZino, other than simply changing the rules to the game in question, which you will know (for example, if we paid out 6 to 5 on a blackjack instead of 3 to 2, you'd be able to easily notice this).

I posted this here because I noticed that bitzino is very pedagogical on the concept of provable fairness, and the subject is being actively discussed here.

Thank you for posting this, and feel free to follow-up if I wasn't clear enough in my explanations! Also, in case you didn't know, we wrote up a detailed article about the technical aspects of our provably fair system. You can read it here: https://techblog.bitzino.com/2012-06-30-provably-fair-shuffling-through-cryptography.html

We have played around 100,000 hands of blackjack at Bitzino over the passed 6 months with success. Is there anyway to get a hand history so we can break this down in a chart?

regards
alan
sr. member
Activity: 266
Merit: 252
I have a question on how the provably fair system can resist collision scams.

I know this would be extremely difficult in the bitZino case (impossible for all practical purposes as long as the hashing algorithm remains unbroken), because the server secret is a coherent JSON string of cards. However, this could be the case on a cointoss setup where the server secret seed is just a random (or random-looking) string.

A malicious server could select two colliding seeds and show their identical hash. Then, upon receiving the client seed, the server chooses the server seed that yields the most favorable outcome and reveals it to the client, who has no means to know about the existence of the alternate seed. Therefore, the system is not provably fair.
Know collisions exist for the still widely used MD5 algorithm, and theoretical collisions (a significant reduction of the entire search space) are possible for SHA-1.

A possible solution could be that in the first step, the server combines its secret seed with a public nonce and shows the combined hash. This ensures that no collisions are available.

What do you think?

Thanks for the question oriolpont! bitZino uses the SHA256 hashing algorithm in our provably fair process, so our users are not susceptible to a hash collision attack as you describe. The SHA256 hash algorithm is the same one used for bitcoin mining, so if hash collisions in SHA256 become possible at some point in the future, we'll have a much larger problem on our hands than just bitZino's provably fair system.

Thank you, at least someone told the truth about it.  I was trying to say this for a long time and no one would listen lol.  Also they can effect the odds without you evening know and still show the correct hash. This dont mean anything with the provable fair system.

We cannot influence the odds of any wagers you place in bitZino, other than simply changing the rules to the game in question, which you will know (for example, if we paid out 6 to 5 on a blackjack instead of 3 to 2, you'd be able to easily notice this).

I posted this here because I noticed that bitzino is very pedagogical on the concept of provable fairness, and the subject is being actively discussed here.

Thank you for posting this, and feel free to follow-up if I wasn't clear enough in my explanations! Also, in case you didn't know, we wrote up a detailed article about the technical aspects of our provably fair system. You can read it here: https://techblog.bitzino.com/2012-06-30-provably-fair-shuffling-through-cryptography.html
newbie
Activity: 53
Merit: 0
I have a question on how the provably fair system can resist collision scams.

I know this would be extremely difficult in the bitZino case (impossible for all practical purposes as long as the hashing algorithm remains unbroken), because the server secret is a coherent JSON string of cards. However, this could be the case on a cointoss setup where the server secret seed is just a random (or random-looking) string.

A malicious server could select two colliding seeds and show their identical hash. Then, upon receiving the client seed, the server chooses the server seed that yields the most favorable outcome and reveals it to the client, who has no means to know about the existence of the alternate seed. Therefore, the system is not provably fair.
Know collisions exist for the still widely used MD5 algorithm, and theoretical collisions (a significant reduction of the entire search space) are possible for SHA-1.

A possible solution could be that in the first step, the server combines its secret seed with a public nonce and shows the combined hash. This ensures that no collisions are available.

What do you think?

Thank you, at least someone told the truth about it.  I was trying to say this for a long time and no one would listen lol.  Also they can effect the odds without you evening know and still show the correct hash. This dont mean anything with the provable fair system.

Just let me insist, if I have not been clear enough before, that this is more a problem for gambling dice than for bitzino. "Provably fair" dice sites have random-looking seeds which could be collidable (at least in theory), while bitzino uses a random shuffled JSON struct, which is extremely more difficult to collide. Still, I propose that my suggestion would reduce this tiny provability to zero and make the system truly provably fair (IANAC though).

I posted this here because I noticed that bitzino is very pedagogical on the concept of provable fairness, and the subject is being actively discussed here.
sr. member
Activity: 364
Merit: 250
I have a question on how the provably fair system can resist collision scams.

I know this would be extremely difficult in the bitZino case (impossible for all practical purposes as long as the hashing algorithm remains unbroken), because the server secret is a coherent JSON string of cards. However, this could be the case on a cointoss setup where the server secret seed is just a random (or random-looking) string.

A malicious server could select two colliding seeds and show their identical hash. Then, upon receiving the client seed, the server chooses the server seed that yields the most favorable outcome and reveals it to the client, who has no means to know about the existence of the alternate seed. Therefore, the system is not provably fair.
Know collisions exist for the still widely used MD5 algorithm, and theoretical collisions (a significant reduction of the entire search space) are possible for SHA-1.

A possible solution could be that in the first step, the server combines its secret seed with a public nonce and shows the combined hash. This ensures that no collisions are available.

What do you think?

Thank you, at least someone told the truth about it.  I was trying to say this for a long time and no one would listen lol.  Also they can effect the odds without you evening know and still show the correct hash. This dont mean anything with the provable fair system.
newbie
Activity: 53
Merit: 0
I have a question on how the provably fair system can resist collision scams.

I know this would be extremely difficult in the bitZino case (impossible for all practical purposes as long as the hashing algorithm remains unbroken), because the server secret is a coherent JSON string of cards. However, this could be the case on a cointoss setup where the server secret seed is just a random (or random-looking) string.

A malicious server could select two colliding seeds and show their identical hash. Then, upon receiving the client seed, the server chooses the server seed that yields the most favorable outcome and reveals it to the client, who has no means to know about the existence of the alternate seed. Therefore, the system is not provably fair.
Know collisions exist for the still widely used MD5 algorithm, and theoretical collisions (a significant reduction of the entire search space) are possible for SHA-1.

A possible solution could be that in the first step, the server combines its secret seed with a public nonce and shows the combined hash. This ensures that no collisions are available.

What do you think?
sr. member
Activity: 266
Merit: 252
Sorry about the recent downtime! We were indeed offline for a few hours due to some unexpected hardware issues. We work hard to keep our uptime percentage high, so we've identified and fixed the underlying issues that caused this downtime. Thanks for your understanding!
newbie
Activity: 6
Merit: 0
It's down for me right now.

Anyone else experiencing the same problem?
legendary
Activity: 1022
Merit: 1000
Any ideas why the site is down?

No.  While there seem to be frequent ddos attacks on many BTC sites I have gotten spoiled the last several months with bitzino always being up.  I hope they sort it out quickly and that it isn't anything that seriously threatens the site.

I did check my deposit addy and there are still some btc in it, so at least it's not an "all balances are gone" level crisis!

Edit:  And it's back!  Whew!
Pages:
Jump to: