Bitcoin Forum
March 28, 2024, 09:17:23 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 [38] 39 40 41 42 43 »
  Print  
Author Topic: bitZino - Bitcoin Casino - Blackjack, Roulette, 3 Card Poker, Slots and more!  (Read 82291 times)
applelover
Full Member
***
Offline Offline

Activity: 160
Merit: 100


View Profile
October 23, 2013, 10:05:02 PM
 #741

libertaad how many people did it take to build the code and backend to your site? it has a nice look.
Bitcoin addresses contain a checksum, so it is very unlikely that mistyping an address will cause you to lose money.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711617443
Hero Member
*
Offline Offline

Posts: 1711617443

View Profile Personal Message (Offline)

Ignore
1711617443
Reply with quote  #2

1711617443
Report to moderator
1711617443
Hero Member
*
Offline Offline

Posts: 1711617443

View Profile Personal Message (Offline)

Ignore
1711617443
Reply with quote  #2

1711617443
Report to moderator
Casino Gambling Guy
Member
**
Offline Offline

Activity: 63
Merit: 10


View Profile
November 06, 2013, 07:50:29 PM
 #742

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.

The best way to say thank you:

BTC: 1Mfq5PUZpBVd7nhQ6aMa5SeKxeDKKDyr6B    eToken: eLJTb8KefyPhHNLpFDtQVhbs2hN2kGvBTD
libertaad (OP)
Sr. Member
****
Offline Offline

Activity: 266
Merit: 252



View Profile WWW
November 06, 2013, 08:37:25 PM
 #743

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
Legendary
*
Offline Offline

Activity: 1137
Merit: 1000



View Profile
November 07, 2013, 02:32:47 AM
Last edit: November 07, 2013, 06:04:52 AM by jpoker272727
 #744

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
Newbie
*
Offline Offline

Activity: 34
Merit: 0


View Profile
December 10, 2013, 07:20:41 PM
 #745

Any ideas why the site is down?
galbros
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000


View Profile
December 10, 2013, 09:02:22 PM
Last edit: December 10, 2013, 10:17:50 PM by galbros
 #746

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
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
December 13, 2013, 04:18:28 PM
 #747

It's down for me right now.

Anyone else experiencing the same problem?
libertaad (OP)
Sr. Member
****
Offline Offline

Activity: 266
Merit: 252



View Profile WWW
December 14, 2013, 09:08:20 PM
 #748

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
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
January 29, 2014, 12:35:15 PM
 #749

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
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250


View Profile
January 29, 2014, 03:12:47 PM
 #750

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.

⚂⚄ Pocket Dice — Real dice experienceProvably Fair
Free BTC Faucet
⚅⚁
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
oriolpont
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile
January 30, 2014, 02:08:49 AM
 #751

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 (OP)
Sr. Member
****
Offline Offline

Activity: 266
Merit: 252



View Profile WWW
January 31, 2014, 01:07:27 AM
 #752

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
Sr. Member
****
Offline Offline

Activity: 602
Merit: 260


View Profile
January 31, 2014, 01:16:37 AM
 #753

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 (OP)
Sr. Member
****
Offline Offline

Activity: 266
Merit: 252



View Profile WWW
January 31, 2014, 01:58:16 AM
 #754

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
Sr. Member
****
Offline Offline

Activity: 449
Merit: 250



View Profile
January 31, 2014, 03:15:19 AM
 #755

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

Activity: 53
Merit: 0


View Profile
January 31, 2014, 08:35:07 PM
 #756

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
Newbie
*
Offline Offline

Activity: 55
Merit: 0


View Profile
February 03, 2014, 04:41:31 PM
 #757

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
Legendary
*
Offline Offline

Activity: 2940
Merit: 1327



View Profile
February 04, 2014, 12:43:16 AM
 #758

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.

Just-Dice                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   Play or Invest                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   1% House Edge
aksplace
Sr. Member
****
Offline Offline

Activity: 602
Merit: 260


View Profile
February 04, 2014, 12:45:51 AM
 #759

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 (OP)
Sr. Member
****
Offline Offline

Activity: 266
Merit: 252



View Profile WWW
February 04, 2014, 11:42:28 AM
 #760

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.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 [38] 39 40 41 42 43 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!