I'm not a gambler, but I live near a casino. I see how much money the casinos make because their fines for cheating are nowhere near the money they make. So I hope what you are doing will change the world of gambling.
Having said that, I believe your service needs to be promoted in a big way. I have some ideas if you are interested.
Thanks for the support! I'd love to hear what ideas you have to promote bitZino. Ultimately, I'd really like to make bitZino appeal to the non-bitcoin crowd. I really want regular people to come use the website, have a lot of fun gambling with play money, and then take the time to learn about bitcoins, so they can step up their game. |
|
|
|
- Alternative cash-in mechanism (MT Gox codes, or importing private keys)
Changing 50!  I just wanted to share this to show what is coming. Currently paper bitcoins are already possible with BitAddress.org, but "coming soon" will be these. - http://bitcointalk.org/index.php?topic=92969.0Though you would only use these for gifts or for transferring bitcoins among parties where there is mutual trust, these paper coins make bitcoins accessible to a wider segment of the population. I'm hoping that bitZino prioritizes the ability to import (redeem) private keys, as I know exactly what will happen next. Anyone behind the counter that cares to can become a local bitcoin exchange (well, for selling bitcoins, at least). So at the coffee shop I pay for my coffee and hand over $5 for a fraction of a bitcoin, scan the paper voucher into bitZino, and play a few hands of blackjack while getting my caffeine fix. By the time I leave there will be so much dopamine coursing through my veins I might just return after lunch for more. :-) That looks really cool, Stephen! We're currently heads-down working on the finishing touches to our Video Poker game, but we'll be prioritizing importing private keys after this. From a cursory glance, I think it really shouldn't be that hard, and empowering bitcoin notes would be a huge benefit! |
|
|
|
Min and max cash out are 1 satoshi.
I'm glad I lost all my money or it would have taken years to withdraw with such a low max cashout! that must be murder on the TX fee's Haha, woops! I meant to say that the min cash out is 1 satoshi, and there is no max cashout. I'd hate to force us to pay 5,000x transaction fees for every withdrawal  |
|
|
|
I just played here for the first time and really liked it. Nice interface, I like the "account settings" page where you can select how long before you are auto-logged out, as well as what currency to use and so forth.
My one complaint was after screwing around with "playmoney" for a while, I sent in 5 BTC to play with for real and couldn't figure out how to change over from playmoney to real money. I kept trying to place bets, but wound up only placing playmoney bets.
I finally clicked something that said, "Leave" and I thought I would be leaving the site, but in fact it let me start playing again for real money!
Which happened to work out in the end since when I was trying to bet real money I kept losing all my play money chips to a bad run of cards, but once I finally figured out how to switch to real money I ran hot and made 2 bitcoins in a few minutes.
Anyways, I think it should be more user friendly since I could not figure out how to bet real money on your games and just stumbled on it by dumb luck and clicking buttons and stuff.
Thanks so much for the feedback! This is a great example of a time where real-world user feedback is of paramount importance. We've been trying to do as much internal testing of our flows as possible, but this is clearly something we've missed! We used to have a link below play money tables that read: "You're playing with play money. Click here to start playing with real bitcoins", but we got rid of the link recently. Your post is a clear indication that the link is necessary for the flow of when a user is just getting started playing. We have just added the link back, so it should be easier for you and for future new users. Thanks! |
|
|
|
The words "your" and "deposit" overlap, as seen in this screenshot:  It's probably got to be a browser bug, since the HTML looks fine. I'm using Chromium 18.0.1025.151 (Developer Build 130497 Linux) Ubuntu 12.04. Ah, I see it in Chromium 18 myself as well. Interestingly, it's not in Chrome 19. Also interestingly - the layout glitch goes away if you refresh the page. I do have an idea of what causes this bug - I think it's due to the way webkit handles re-layouts of the page - I'm going to have to dive a little deeper though to figure out a fix. Thanks for the report! I never was able to figure out what was causing this. But, it looks like the most recent update of chromium caused the issue to just be fixed, so I guess it was a browser bug. |
|
|
|
|
Thanks to everyone that has been offering feedback and suggestions to make bitZino a better place. We have definitely been listening! We just launched the following changes:
- Split Aces can now be hit and resplit. This brings the house edge for our blackjack game down to only 0.398%.
- QR Codes for deposit addresses: If you use your phone as your primary wallet, you can now scan your bitZino deposit address using a QR Code.
- Auto-logout after inactivity. To increase security, you can optionally set your account to auto-logout. As always, your games will continue right where you left off in the event that you log out.
- Small balances are no longer displayed in scientific notation :p
We also have these other features on the roadmap, but realistically, we'll probably be focusing on adding new games (such as draw poker) before doing these features:
- Alternative cash-in mechanism (MT Gox codes, or importing private keys)
- Cancelling withdrawals
- Changing the base currency of a live table (we really want to fix this, but its complicated to get the UI and user flow correct here - there's a lot of corner cases)
- Showing the withdrawal screen in the user's base currency as well as whole bitcoins (again, the UI is difficult to get right here - our internal user testing found that adding too much information to this screen could confuse users)
- Creating additional deposit addresses (After researching this, we found it has the potential to slow down bitcoind if we allow too many addresses to be added. There are workarounds, but it'll take time to figure it all out)
- Playing for real BTC without actually registering
- Keyboard shorcuts
- Sounds
- The option to disable animations
- Better reveal animation, utilizing CSS3 3D transitions
Thank you so much to everyone for their feedback, and please keep it coming! Our primary objective at bitZino is to please our customers, so we will always listen carefully, and act on your feedback!
|
|
|
|
libertaad: I know youīre doing your best effort to prove the game is fair, but using math.Random() you are proving nothing. I would be the same as skipping the client_seed stuff and telling the users to trust you because youīre good person or had no complains in the past. Either you provide a secure system or your efforts are worthless. If you want to convince your users there are plenty of companies that audit the PRNGs like iTech Labs. , eCOGRA, etc.
It seems that with little additional effort (providing client-side user programmed scripts to choose the client_seed) you could still take advantage of current developed system and secure it.
best regards, Sergio
Thanks for the feedback, Sergio. I really do appreciate it! I believe you're right that a greasemonkey client-side script which used a CSPRNG to generate the client_seed would drastically improve the quality of the overall system, especially for users with insecure browsers. There are some talks in other threads about members of the community building this on their own, which I've offered to support. I think would be the absolute best: having a 3rd party script which verifies all hands, and stores a history of every hand played would be ideal. Before that script is built, I still hold that this system is vastly superior to most other online casinos. |
|
|
|
I've not researched the subject myself, but reading other peoples research it's clearly stated that Math.Random can be predicted with high accuracy: it is seeded with the system time each time a new page or new tab is open.
...
So, either you allow the user to supply the random via a greasemonkey script or fairness will never be guaranteed.
Fortunately, due to the nature if bitZino being a webapp, this already is possible! Any user is free to create a greasemonkey script which modifies the client_seed using their own randomness source. Additionally, users are free to manually enter a client_seed before every hand. Also, as an additional measure, because the initial_shuffle is provided directly to the user after every hand, any suspicious user could easily to entropy analysis on all the hands they've played and prove whether or not the server is serving up truly random initial_shuffles. |
|
|
|
I just played a hand and think that the game might have malfunctioned. Here is the info:
I was dealt two aces against a dealer jack. I split them, and the two hands were blackjack and ace-ace. I was not given an opportunity to split the second ace-ace and was forced to accept a value of 12, which lost against the dealer's 18. By "not given an opportunity", I mean the game just proceeded without waiting for a user choice, the same way it would were it a blackjack.
Final shuffle: qA0eNDIgGCfpAqdMoxM513qeGtw1zzpnlt8CrLK9MxFjs...
EDIT: Nevermind: rules clearly state "cannot act on split aces".
I was dealt two aces against a dealer jack. I split them, and the two hands were blackjack and ace-ace. I was not given an opportunity to split the second ace-ace and was forced to accept a value of 12
We discussed this a couple of days ago. I thought the rules had changed since then to allow hitting split aces, but I guess not: I think I will change the rules to allow for both hitting and re-splitting of split aces, which is more fun, and it'll bring the housed edge down to a meager 0.398%.
Sorry about that. We have not changed the rules yet. Right now we're pretty busy with a server upgrade, so none of the major changes suggested in this thread have been implemented yet. A rule change like this is pretty minor code-wise, but we're also re-running all our monte carlo simulations just to ensure everything adds up. Look for the rule change to hit later this week sometime. |
|
|
|
What isn't working for you on your iPhone? I have tested it on an ipod touch, and everything seemed to work well, but I may need to dig deeper if you're seeing issues.
Hrm.... IIRC the 'cards' never loaded. However I just tested it under chrome and safari on my iPhone 4S (same device as before) and it is fine. So I honestly don't know what the problem was. If people have troubles in the future maybe force closing safari might resolve it? Hm, strange. It may have just been due to poor networking, but it could be a genuine problem with the way iPhone handles network timeouts or other failure cases. I'll stay on the lookout to see if I can ever replicate this behavior. Thanks for the report! |
|
|
|
That is pretty slick, however FYI: it doesn't work on my iPhone, but DOES on my iPad. Wonder if it could be a size issue.
What isn't working for you on your iPhone? I have tested it on an ipod touch, and everything seemed to work well, but I may need to dig deeper if you're seeing issues. bitZino is good example for gaming industry and this is only the beginning
nice work
Thanks! I think this would make a great browser extension too, blockchain.info does this to make sure nothing has injected javascript.
The bitZino verifier.
Actually this opens up a whole world of hand analysis / logging plugins too.
I would love to see some bitZino greasemonkey scripts and browser extensions! If any developers are interested in building anything like this, please feel free to reach out to me. I intend to keep the structure of the DOM on bitZino relatively the same going forward, but it would probably help to coordinate a little just to help ensure nothing breaks when I update the site. |
|
|
|
Nice site. Good code. I lost a couple coins to you just messing around. I don't know if the hashing on the customer side is really necessary, but it's a nice touch, and you implemented it well. Now you just need a full-time customer service staff to handle Dooglus... and watch out, he wins more than he loses  Thanks for the praise! It means a lot coming from another programmer  You, um ... , you don't get out much into the real world nowadays anymore, do you?
Hey! Just because I like my numbers displayed in a logical format doesn't mean I don't get out Always display precision down to the satoshi. So if I have 0.1 BTC, it shows 0.10000000 BTC.
We'll get used to it.
I like this approach. It's both logical and palatable. |
|
|
|
Hi Libertaad, nice to meet you!
Nice to meet you too! What you say is only partially true: since Mersenne Twister is not a Cryptographically-Strong Pseudorandom number generator (CSPRNG) there is the possibility that the possible pre-images could be computed to maximize some statistical properties of the Mersenne Twister output. The advantage might be subtle, but it could be done, in theory.
My suggestion is to use a client_seed much longer (say 80 bits) and a CSPRNG.
A key reason that we went with Mersenne Twister for the reshuffle phase was because we place a lot of value on the reference implementation. We wanted an accessible reference implementation, that any of our end users could run. This meant it had to be in javascript. We didn't want to just have this awesome provably fair shuffling algorithm, but make it basically impossible for any of our end-users to truly verify anything. We also didn't want to re-implement any PRNG's in javascript, because this would defeat the goal of having a simple reference implementation. Our reference implementation is less than 100 lines of code, but it does rely on an existing Mersenne Twister implementation. Great! But the problem is that the user has to manually check the shuffles every time. There should be a way to automate the checks, but in a way the the checking code is not sent by the server, but given by the user. An interfase between the web page and a local application.
I believe that a great way for a savvy user to do this on their own would be through a greasemonkey script. This is possible since bitZino is an HTML5 app. Since greasemonkey scripts are in javascript, the user could even use our reference implementation if they desired There are (possibly) two other problems with your protocol:
1) The origin of the code that choses the client_seed:
I havenīt seen the page, but I doubt the user can provide the random seed manually in an edit box.
If not, then the server-sended client-side javaScript code could choose the number in a predictable way, and the user has no way to find it.
A "fake" webpage could be sent with a probability of 1/10, so the user chances of finding it while reviewing the source code is low.
bitZino actually does allow you to edit the client_seed if you so desire (you can see the interface for yourself if you'd like with a play money table at https://bitzino.com/blackjack). While it would be possible for us to send down fake javascript on occasion to generate client_seeds that favored us, we would be guaranteed to eventually be caught if we did this. This avenue of attack could also be stopped in its tracks by the user running a greasemonkey script which always submitted their own client_seed. In this way, the user would never be depending on the javascript on the page to generate the seed for them. 2) The way the client_seed random is chosen:
Again, I havenīt seen the source code of the webpage where the client_seed is chosen. (I havenīt played in your site) but I guess it has some javaScript code that calls Math.random(), which is not cryptographically secure and so itīs predictable.
How do you compute the client_seed ? You should use a CSPRNG, such as the one provided by SJCL namespace sjcl.random (I havenīt tested it myself)
Could you post the source code of the webpage where the client_seed is chosen ?
We are indeed using Math.random() to generate the seed. The source code, if you're curious (it creates a 24 character base-62 string): function setRandomClientSeed() {
var a = [];
for(var i = 0; i < 24; i++) {
var val = Math.floor(Math.random() * 62);
val += 48;
if (val > 57) { val += 7; }
if (val > 90) { val += 6; }
a.push(val);
}
$('#client_seed_input').val(String.fromCharCode.apply(null, a));
}
Once again though, the user could utilize a greasemonkey script to create their own seed, and therefore not rely on the page javascript for security at all. We did think about making this whole algorithm greasemonkey script from the beginning - which would have satisfied all of your issues regarding the server sending down tainted JS. The reason we chose not to do this primarily as a greasemonkey script was once again about accessibility. We wanted 100% of our users to be able to verify their hands if they chose to. I still may make a greasemonkey verifier, but I think it would actually be better if the greasemonkey verifier came from the community, rather than from us. |
|
|
|
Another observation:
When the dealer's playing, the slow reveal of the hole card takes longer than his next 3 or 4 cards. So for a while I can see his 1st, 3rd, and 4rd card before I can see the 2nd card. Which is just a bit weird.
Yeah - this is a known issue. It's due to the way that jQueryUI interacts with jQuery itself in certain situations. I'm exploring using CSS3 3D animations to make the reveal much more slick - similar to the technique here: http://thewebrocks.com/demos/browsermemory/It's kind of traditional to use a different bitcoin address for each transaction.
Personally I prefer one address for my address book. However having a new address button woul be nice, I think GLBSE does this.
I like the idea of the "New address" button! I think I'd limit it so that the button only showed up after a each new deposit that you make. This would limit us from having to potentially map thousands of addresses to a single account. I had a run of losses, and now my balance has gone all scientific notation:
This is actually intentional :/ But I can see that it's not exactly the most user-friendly. The problem is, the only alternative I can think of is just to display a lot of zeros, which I also don't think is great: eg, can you easily see the difference between "0.0000045" and "0.00000045"? It's way easier to see the difference when these numbers are displayed as "4.5e-06" and "4.5e-07". But, I'm open to any suggestions you may have here. How do other bitcoin sites display very small numbers to users? |
|
|
|
And don't forget that timing me out because I've been sat half-way through a hand for 15-minutes should log me out, but leave me in the same place when I log back in. Yup, that's definitely how it will work! Sometimes when I reload a page that made a POST request, it re-makes the POST request. Is it only when the POST times out that the reload does a GET?
Hm, I'm not sure what the exact behavior is for browsers, but I would suspect that if the POST request times out, the browser would prompt you to redo the POST when you try to refresh the page. I know that if you select the URL bar and hit "Enter" it will always to a GET request though. Either way - I've implemented the GET handler for /table_transfer, so you should at least be able just get redirected back to the blackjack table rather than just seeing a 404 page. |
|
|
|
Probably a silly point, but "lose -2" reads strangely. If I lose -2, don't I win +2?
It should probably read more like "Lose: -2" he wants to tell that hand is a losing hand and the amount taken from your balance.
Good suggestions! I went ahead and made this change for all the outcome messages. I agree that it is much more clear. |
|
|
|
There's one other feature that might be useful -- user configurable timeout, so that like 15 minutes of inactivity I need to log back in to play. (optional, of course)
Good call! This would be really good for users that play with a lot of BTC, and want some extra security. We are also likely going to add 2-factor auth, and email confirmations for all withdrawals in the near future. I was wondering about timeouts too. My Internet connection is pretty flaky here. What happens if it goes down for an hour part way through a hand? Can I expect the hand to continue when I get back online? What if I click 'hit', but the connection is down at the time? Will the client deal nicely with not getting a server response and let me try again later?
I guess ideally I'd like to be able to have my browser crash part-way through a hand, then log in on a different computer and see the half-finished hand still in play. But maybe that's expecting too much.
We are fully resilient to internet timeouts. All actions you take on bitZino are atomic. If your internet connection dies right as you hit the "Bet" button - your action will either make it to our servers or not. If it does, then next time you reload the page you'll see the table as if you had made a bet. If the action doesn't make it to our servers, then next time you reload, you'll see the table as if you hadn't made a bet. We also keep tables around pretty much indefinitely - so if your internet connection dies mid-bet while you're about to go on a 3 day vacation, you can come back 3 days later and see your table exactly as you left it. My Internet connection is pretty flaky here. What happens if it goes down for an hour part way through a hand? Can I expect the hand to continue when I get back online?
Funnily enough, my Internet just went down. While it was down, I clicked 'buy in', and eventually got an error page from Chromium. When the connection came back, I refreshed the page, and got: Not Found
The page you were looking for doesn't exist.
You may have mistyped the address or the page may have moved.
The browser's address bar is now showing https://bitzino.com/table_transfer rather than the usual address, but I didn't change it. (So I guess that answers my question!) Ah - this is because your connection died while it was making a POST request to /table_transfer. And, now that you're trying to reload hte page, it is doing a GET request to /table_transfer, which isn't implemented. I will implement the GET request for this action so that it just does a redirect back to the table. Regardless of the Not Found error though - your game should still be in a non-corrupt state. Either our server received the POST to /table_trasnfer, and you got bought-in, or it didn't see the request, and you didn't get bought in. If you just go back to the main page at https://bitzino.com/blackjack, you'll be able to see what state the table is in. |
|
|
|
Hi Sergio! I'm the owner and primary developer of bitZino. Thanks for the feedback! I relish the opportunity to defend our approach to shuffling as truly Provably Fair. 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 believe that the blog post you linked to has a pretty good discussion about most of your points, but I'll take the time to individually address all of your critiques: (1) Client_seed is not big enough (32 bits) to assure a fair statistical distribution. The server can try each possibility in advance...
The client_seed is only used to reshuffle the deck, so it's not necessary to use it to be able to represent the full set of possible decks. In effect, the reshuffling is like cutting the deck, but significantly more robust. Even if the server could analyze all possible deck combinations before each shuffle, it wouldn't help. This is because the Mersenne Twister has the property of having a Uniform Distribution, which means the avenue of attack of "creating a pre-shuffled deck such that all possible re-shuffled decks still favor the house" is impossible. (2) The server knows the shuffled deck (every card) BEFORE the user, so the server can abort the game (showing any strange error message) if the deck is too good for the user.
Even if there is a server error prior to the deal, the user can still confirm that the server didn't change the pre-shuffled deck - as long as the `Hash(secret)` which is presented to the user doesn't change when the user reloads the page, they will know the server is being honest. I do agree though, that if the `Hash(secret)` changes, this would be a clear indication that the house is cheating. (3) Last but not least, the site is HTML5 only (no open source client application), so there is no way to know if the client-side javaScript code is actually verifying anything !!!
The code for the Javascript Hand Verifier is indeed open source! If you view the source for that page, you will see the algorithm implemented in 100 lined of clean, well-commented javascript. If you don't trust the javascript though, you are free to re-implement your own verifier - that's why I created the detailed blog post as well as the reference javascript implementation - I want to be as open about this whole process as possible. (4) Where is the "proof" for the "Provably Fair" algorithm?
Ok, I admit there is no rigorous mathematical proof to accompany the algorithm - but that's why it's not "Proven" - it's just "Provable". I do believe a rigorous mathematical proof could accompany this, and prove that it would be NP hard to cheat a user at dealing if this algorithm is followed. You could say it's just in the theory stage right now The only way to implement secure card games on the Internet is by using Mental Poker protocols (crypto newbies, check it on Wikipedia). And it happens that I designed the fastest MP protocol so far... humbly , for the lazy I'm a big fan of these types of approaches, and the general guiding principal is what drove me to make bitZino provably fair. But, I disagree on your assessment that MP is the only way to have a secure game. MP is great for situations when neither player can know the shuffle of the deck. But in a casino game's use case, it is not a problem for the house to know the shuffle - as long as it doesn't know the shuffle until the moment the game is dealt (again, assuming that `Hash(secret)` doesn't change in the event of an error - which would be a clear indication that the house is cheating). Thanks again for the critique! I truly do love how the bitcoin community embraces cryptographic approaches to solve real-world problems, and I also love how it's rigorous in its critique of systems that aren't truly secure. Please, bring on any more critiques you have, I'd love to continue the discussion! |
|
|
|
Took a look at this last, on my iPad. I lOve it! And I am not really a BJ person, great job!
Can I ask what libraries you are using, or did you write an entire HTML5/canvas graphics engine yourself?
Thanks for the praise! I'm glad it works well on your iPad - that's one of the huge benefits of HTML5 - automatic cross-device compatibility We make use of jQuery and some parts of jQueryUI for the animations - but for the most part, we're just using pure HTML5 and CSS3. Specifically - we make heavy use of HTML5 -data attributes for communication between the client and the server. We also use CSS3 transitions. We're planning on rolling out some 3D CSS transitions when we can work out some of the cross-browser kinks. Wow. You really are open to feedback aren't you!
Yup! That's one of our core philosophies - stellar customer support across the board. This is why we spent so much time creating the provably fair shuffling system - we wanted our customers to know they were getting a fair game. I don't know if you're aware of how big the swings can be in blackjack. Offering a 10 BTC max bet exposes you to the possibility of some pretty big losses if someone plays the max bet and has a good run. Maybe you've considered that and are prepared to lose a lot, but I thought I should mention it. There's probably a reason the other sites offer less than half that as their max bet.
We are aware of the potential for swings, and we are fully capitalized to handle whatever swings come our way. We've done extensive statistical analysis, including random distribution analysis, and monte carlo simulations, in order to ensure that our risk of ruin is infinitesimal. I made a small deposit last night, played a few hands, and withdrew - mostly just to check out how it worked.
It all went pretty smoothly, but I had the following comments:
* it seems you wait for 7 confirmations before marking my deposit as 'confirmed'? that seems like a lot, but since you allow me to play unconfirmed balances it's not a problem
It should just be 6 confirmations - which I admit still is actually quite a lot for smaller transactions. We are thinking of lowering this for smaller withdrawals, but we just want to be careful to not expose ourselves to any double spend attacks, which we've known has been the downfall to other bitcoin sites in the past. Since we allow you to play with 0 confirmations, we don't see this as a huge issue though. * if I had been able to 'cancel' my withdrawal request, I would have, and would have played more hands. Is there any reason you wouldn't allow players to cancel a pending withdrawal request?
That is a great point. We actually have the ability to cancel withdrawals on the backend, we just need to build a UI for it. Finally, I just noticed a small issue: if I click my name in the top right, select a new 'base currency', click 'update', then click 'back', then the "Welcome to Blackjack!" box in the centre of the page still shows my balance in the old currency units. So if I was in mBTC before, but have less than 1 mBTC left, so I switch to uBTC, I still can't buy in because the buy-in box is still prompting for the number of mBTC to buy-in with.
If I click 'leave' in the top right then the currency units update, but that's a workaround I shouldn't have to use.
Ah yeah - that is indeed a poor user flow. We are probably going to change the whole concept how base currency works, such that you can play at a table in a different base currency than your account's base currency. Because you really shouldn't have to change your account settings just to temporarily play at a lower limit. Keep your eyes peeled for this change! I just noticed that whatever the currency unit I set, the withdraw screen is in whole bitcoins. It might make more sense to use the preferred base unit there too (and anywhere else that you show currency values - like in the history of deposits).
Yeah, good point. We figured that since you're withdrawing back into the real bitcoin network at this point, that it would make more sense to show BTC on this screen. But, given your feedback, I think it would be good to show the balance in both your base currency, and in BTC. Thank you all so much for the feedback! This really is incredibly valuable to us as we continue to grow bitZino and make it a better site for all comers. Dooglus, and Stephen Gornick - I've added a BTC to your accounts to thank you. Thanks again! |
|
|
|
so it's a 0.66% house edge if you play optimally.
Are you aware that bitjack21 has only a 0.45% edge (they stand on soft 17), and strike sapphire's is only 0.50% (only 6 decks, let you hit split aces, but only split to 2 hands)? I don't know about the other bitcoin blackjack offerings, but both of these have more attractive offerings than bitzino. Thanks for the heads-up! I was just using what I thought were standard rules, and hadn't really considered exactly what every else's house edge was. I think I will change the rules to allow for both hitting and re-splitting of split aces, which is more fun, and it'll bring the housed edge down to a meager 0.398%. Well, the input does affect the output...
Heh, of course it does  I meant to say that it could affect the output as the algorithm runs - ie, it could rely on the state of the deck in order to determine which operations to take in future steps (which I think algorithms like AES do). If this were the case, an attacker could presumably choose a seed that always brings certain cards to the top of the deck, regardless of the initial_shuffle. ie. you really don't need salt in this case, and so can simplify the verification process.
I am paranoid I know, but ultimately, I don't think it adds that much complication, and it does let me feel better about letting clients choose a seed which determines the ultimate outcome of the deck |
|
|
|
|
Show Posts
