bitZino - Bitcoin Casino - Blackjack, Roulette, 3 Card Poker, Slots and more!

[applelover]

libertaad how many people did it take to build the code and backend to your site? it has a nice look.

[Casino Gambling Guy]

Hi, I'm an affiliate marketer looking to sign up and add bitZino to my list. I looked but could not find any info at all yet I do see some review sites have affiliate codes. Please let me know how to obtain one, thanks.

[libertaad]

We've received reports that scammers are using the nick "Bitzino" on IRC in order to attempt to solicit investments. I just want to state here that we are not seeking any investments, and we do not have a presence on IRC. If you see anyone using our name in order to solicit investments, it is most definitely a scam.

for the seed i can even enter unicode like  ٩(●̮̮̃•̃)۶

Ah, good point! Our client-side javascript will only generate alphanumeric strings, but our backend does accept any valid UTF8 string.

libertaad how many people did it take to build the code and backend to your site? it has a nice look.

Thanks for the kind words! I can't say for sure how long it took to initially build, but I can say that the work is never done.

Hi, I'm an affiliate marketer looking to sign up and add bitZino to my list. I looked but could not find any info at all yet I do see some review sites have affiliate codes. Please let me know how to obtain one, thanks.

Thanks for the interest! Please reach out to us via https://bitzino.com/support, and we'll take care of you.

[jpoker272727]

Bitzino is the only site to play on, trust me, Im a big gambler, and its not good, but if u want fair, I'll tell you from my experience, they are 100%.

[Cogine]

Any ideas why the site is down?

[galbros]

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!

[amirov]

It's down for me right now.

Anyone else experiencing the same problem?

[libertaad]

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!

[oriolpont]

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?

[zolace]

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.

[oriolpont]

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.

[libertaad]

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

[aksplace]

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

[libertaad]

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.

[IveBeenBit]

Glad to see you back, libertaad! It's been strange with you being absent from the forums for so long!

[oriolpont]

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.

[ar8003]

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

[dooglus]

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.

[aksplace]

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?

[libertaad]

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.