That sounds bad! I am not able to replicate this issue though. Could you help me out and elaborate a little more? Which buttons require clicking multiple times - the big buttons at the bottom of the table (eg, "Spin", "Repeat Last", etc.), or is it the roulette board itself that sometimes requires multiple clicks. Also, what browser are you using? Finally, if possible, could you post a screenshot of: "It happens a lot when the bet/double button lines up over another number or between two numbers". I'm not sure exactly what you mean here, and a screenshot would help a lot. Thanks!

Also, what's your username on bitZino? I'll comp you as well for helping me out

Thanks for the feedback! 0.25 BTC has been comped to your account

We are planning on adding keyboard shortcuts (it's been on the backburner for awhile now), so hopefully that should alleviate the "back and forth on the trackpad" issue.

Regarding the button order, I'm not sure if there really is any standard button order: I've seen video poker machines where the Hit button to the right of the Stand button, and I've also seen the opposite. So, we just tried to go with an order that seemed logical. Regardless, I think that keyboard shortcuts will help solve this issue, since the keyboard keys will be customizable (so you'll be able to put the hit key to the right of the stand key if you want).

Regarding the double clicks - thanks for the feedback here, this is really valuable! I think we can solve this UI issue by keep the button disabled for a little bit longer after you click.

Thanks again for all the feedback, and feel free to let me know if you have any more!

Sorry that you lost! I'm glad you enjoyed the experience though. If you let me know your username, I'll comp you a quarter BTC to help make up for the loss

I'd love to hear more about what interface quirks you experienced, so we can fix them. We really want the experience to be as polished as possible, so every bit of feedback helps!

Quick update on this feature: We think we've found a good way to do it using the custom transactions feature of bitcoind version 0.7. So, we will be holding off until 0.7 is launched before launching this feature ourselves.

Along with importing private keys, we're also going to add support for 0 confirmation withdrawals. We will do this in the same way SatoshiDice does: the withdrawal will be built off the output of the deposit transaction, therefore a blockchain that doesn't contain the deposit cannot contain the withdrawal.

So far, we have had a very basic implementation for accepting bitcoin payments. Going forward, we're really excited about building more complex behavior using the power that custom transactions will provide us!

Woot! I'm glad you could follow along with my explanation


I would love it if you did this!


Thanks for clarifying, Dooglus!

We really should have these rules explicitly stated though. I'll add them to the rules dropdown.

This is a great idea! As you mentioned, Dooglus did write a python script which verifies the secret and outputs the final shuffle of the deck given the Hash(secret), secret and the client_seed. Additionally, we have a javascript hand verifier located at https://bitzino.com/about/fair. If you are inclined to take a deeper look at the code for our verifier, you can view the source of that page and see the javascript verifier - it's just 100 lines of well-commented code.

However, I understand that you may want to verify on your own without relying on having coding expertise or relying on code that is hosted on our own website. To that end, I've outlined the steps to do this below: (unfortunately, there will be just a little bit of "coding", but it's really just copying and pasting certain commands into a javascript console. This is necessary because there isn't an online implementation that I could find of the Fisher-Yates shuffle algorithm)

Step 1: Verify the Hash(secret) is derived from the secret

After playing a hand of any game at bitzino, go to http://www.movable-type.co.uk/scripts/sha256.html, and copy and paste the Secret in to the box. Click on the "Generate Hash" button, and verify that the hash generated on that website matches the Hash(secret) you see on bitzino.

Step 2: Generate the seed from the client_seed and the server_seed

While still on the same website, copy and paste the client_seed into the box, followed directly by the server_seed (the server_seed is part of the Secret). E.g, if the client_seed is "ABC", and the server seed is "123", the box should have "ABC123" in it. (Also, make sure you're copying the client_seed from "Last hand" on bitZino, not from the "Next hand"). Click on the "Generate Hash" button. Now, keep this page open, because we will be using this Hash later.

Step 3: Set up a javascript console with the Mersenne Twister function

Go to http://jsconsole.com. This is a javascript console, and it's where we'll be completing all of the following steps.

Copy and paste all of the code from https://bitzino.com/static/MersenneTwister19937.js into the javascript console. This will initialize the Mersenne Twister function which will be used later on.

If you'd like to verify that the above code is indeed a pristine copy of the Mersenne Twister, you can download the original zip file from http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/JAVASCRIPT/java-script.html

Step 4: Seed the random number generator

Type the following commands into the jsconsole:


Note that the first line of code isn't actually <hash value from step 2>, you should replace that part with the value you got from step 2.

Step 5: Set up the initial_shuffle

Create a variable in the jsconsole that is equal to the initial_shuffle from bitzino. (The initial_shuffle is part of the Secret).


Step 6: Reshuffle the deck using the Mersenne Twister RNG, and the Fisher-Yates shuffling algorithm

Copy this code into the jsconsole:


At this point, the jsconsole will spit out a value that should be identical to bitZino's final_shuffle.

Final thoughts

I really wish there were an online Fisher-Yates/Mersenne Twister card shuffler, so that every step in this process would be as easy as step 1. If anyone does know of one, please let me know so that I can make this process easier! I also recognize that you are still depending on a lot of code that is just copied directly from me, but I think the fact that it's posted here publicly should show that it is honest, and does what it says it does.

I hope this helps!

We've just pushed another round of changes. These are mostly minor, but I wanted to confirm all the issues you brought up that were addressed:

- The homepage now always goes to the previously played game.
- We handle internet failure more gracefully, by adding a timeout to our ajax calls and displaying an alert.
- Fixed the slightly wonky layout of the Roulette table in Chromium (that was due to CSS rounding issues)


Sounds good! We've already made some progress here, because we were working on Let it Ride, and were considering adding the 3 card poker bets to it. We're focusing on adding craps next, but we'll work on 3 card poker after that!

Welcome to the site! I sent you a quarter BTC to thank you for all the feedback you've been providing


Cool, glad you like it! Our system typically sends withdrawals instantly. The main reason for a short delay is if you have unconfirmed transactions. We require 2 confirmations on all your deposits before sending the withdrawal.


Nice, I'm glad the UI improvements helped

HTML5 is great, because it typically just works on mobile web browsers. We do make sure to test out everything on mobile browsers as well, just to make sure it's all working well. We may eventually do native apps in the future, but for now we are just focusing on a good HTML5 experience.


Good point. We want to make sure not to make the interface too cluttered, but this would probably be useful.


Thanks! This is really exciting. Our first major news coverage!

Thanks as well for the feedback on what you find difficult to understand about the provably fair system. I am definitely aware the education around this is one of our bigger hurdles here, so hearing directly from you what concepts you don't understand is definitely very helpful!

We tried to provide a simple explanation on our website, and a more in-depth explanation on our tech blog, but perhaps our simple explanation isn't simple enough. We'll definitely take your suggestions, and probably rewrite parts of the "simple" explanation.

We've just pushed a change to add a 4th main button to allow you to double all of your active bets. We also now display the sum of your total much active bets. This should make it easier to quickly see how much you're betting, and also make it easier to vary your bets between spins.


This change is now live!


Ah, good catch! It turns out this was because of the arrow, which is actually just a square div rotated 45 degrees, not having a click handler assigned to it. This resulted in the small triangle at the top of the popup not responding to clicks. This is fixed now.



It does make sense that the wheel would just keep spinning forever, because the response from the server is what triggers the animation to stop.  Also, your bet won't get automatically re-submitted to the server - it just makes a single request.

We can probably handle this situation much more gracefully by adding a timeout to the request, and then alerting you that your internet is likely out. We'll look into doing that.


That's a really good idea! I had thought of doing this when I launched Video Poker a while ago, but never ended up executing it. So, thanks for the reminder!

We just pushed a change that fixes many of the bugs people have been mentioning:

- The animation time for fading out lost bets has been lengthened
- The spin button no longer "flashes" in the middle of the spin
- When the popup shows up, the text for the bet is now selected.
- You can now close the popup box by clicking on any of the empty area inside of it. I hope this is a good solution for people that like to bet the inside.


Ah yes, I did mis-read your original post. We experimented with adding these buttons next to the Bet-per-click box, but found that they were somewhat confusing - it was unclear if it doubled the bets on the currently table, or if it just doubled the bet-per-click. In the end, we decided that doubling the bet-per-click isn't really necessary, so it was better to just remove that part of the UI altogether.

However, we agree that it would be nice if you could double all of your current bets....


Yeah, this is not ideal. We are exploring a UI to allow you to make actions on all of your bets on the table (something like a "double all by bets" button), because it's pretty clear there is demand for this.


Yeah, agreed. We're working on incorporating this into the "double all my bets" UI that we're working on, so stay tuned!

By the way, what's your username? I'll comp you some BTC to thank you for the helpful feedback.


Thanks! Feedback like this helps keeps us going


I hope that the ability we just added to click anywhere on the popup to dismiss it should help here! Let me know if not. We definitely want to accommodate all players, including those that like to bet the inside

I added a quarter BTC to your account for the helpul feedback, Kaji.

Thanks to everyone for the feedback!

Thanks! I almost felt bad to launch roulette so shortly after making that post, because I wanted to continue discussing it But instead I had to derail the conversation, haha.

That's a great idea. We don't do that yet, but we definitely should be! We'll add it shortly.


Yikes! That was a bug that got introduced when we launched roulette. Fortunately it was just a display bug. It's been fixed now!

We also pushed out some of the minor bug fixes and tweaks discussed earlier:
- Bet per click is now correctly remembered between hands.
- Reclicking on a bet will increment the bet, rather than dismissing the popup.
  -We decided to not do the change where we only show the popup on the second click - it turned out that this was somewhat of a confusing flow - it was non-obvious why the popup would show sometimes and not other times.
  -We also tweaked the behavior so that the bet is not incremented if the popup isn't already showing unless it's the first click. This allows you to click on a bet to make edits to it without having the bet be modified first.
- The input box gets focus automatically when the bet popup appears (only on non-mobile devices).
- The style of winning bets is changed to have a white drop shadow instead of a red shadow.

Still to do today is some animation timing tweaks, as well as experimentation with hover effects.

Thanks for all the feedback, and keep it coming!

I just realize I never really addressed this in my last post.

We had this behavior at first, but it was really bad on mobile devices, because it brought up the onscreen keyboard, which blocked half the screen. However, I agree that it would be nice on non-mobile devices to have this behavior. I'll see if I can get this to behave ideally on both.

I like this idea a lot. Overall this just seems like a much smoother flow. I'll implement this. Along with Dooglus's recommendations above, I think the overall flow for betting will be much better once we make these changes.


This one may be tough. I think it could potentially get confusing for users too. I'll do some experimentation though and see if it's workable.


This makes sense.

This fits with a long-standing issue we've been meaning to address which is just providing general animation options for all of our games (ie, fast/slow/no animations).


I'll experiment with this. I suspect it could potentially be confusing/overwhelming (I generally don't like to have too much stuff happen on mouseover). You can also always click the "Repeat" button, and then click "Clear" to effectively see a preview.


This makes sense. I'll do it.

Thanks for the detailed feedback! I added a quarter BTC to your account to show my appreciation

Yikes! I agree - details definitely matter, and I don't want to send the wrong impression with such a silly spelling mistake.

It's fixed now Thanks!

Ah yes, this is indeed a bug. We have a fix which we'll be pushing out shortly shortly. Thanks!

What's your username on bitZino? I'll comp you some BTC for helping to find this bug.

Thanks


Yeah, now that I think about it, I agree, red is associated with losing. I like your suggestion of white instead, it looks pretty good.


This makes a lot of sense. I'll make this change. The only thing to consider is how to easily close the popup (since that's the current behavior of re-clicking). You can actually just click anywhere on the table to close it, but that's not necessarily obvious. I think I'll add a 'X' to the top right.


Yeah, this does actually make sense. We're going to have to re-think the popup box somewhat though - I don't want to make it too much bigger. We'll see what we can come up with.

I comped you a quarter BTC, Dooglus for being so helpful with the bug reports and suggestions. Keep it coming though!

Thanks for the feedback everyone, and keep it coming! I love launching new features to this forum, you guys are great!

Haha, shoot, I knew I was forgetting something btw,  I'm pretty sure you're the bet proof-reader I know

We have officially launched Roulette!





I'm really proud of the interface we developed for this game. We have been trying to break away from the common paradigm of simply simulating physical games on a screen. We think we can create much better user interfaces when we utilize all the features that a computer has to offer.

For example, we have been trying to not introduce the chip metaphor into any of our games - we think it's much easier to type a number than drag an drop various chips around the screen. This did pose as somewhat of a challenge for roulette, where chips play an integral part of both how you place your bets as well as how you visualize your bets. But in the end, we think we've created a much better digital representation of roulette than any we've played. Try it out, and let us know if you agree!

Also, like all of our games, roulette is Provably Fair. We utilize cryptography to make it computationally impossible for us to cheat you. You are guaranteed a fair game!

As always, I'm here on the forums, and very receptive to your feedback. If you have any comments at all, please don't hesitate to let me know!

Heh, this is a definitely very interesting question, and I'm happy to talk about it Risk management is one of the more complicated aspects of running a casino, and I have certainly learned a lot about it since launching bitZino. Fortunately, we've got some smart minds with a background in risk management. Before launching any games we do extensive analysis of the game to ensure that our risk of ruin is infinitesimal. This process is fresh in my head because we've been doing extensive analysis of our soon-to-launch Roulette game (which poses unique challenges with its 35 to 1 bets (more on this below)).

This is a paramount process for any honest casino: if the casino's risk of ruin isn't effectively zero, then you as a player are not only playing against the house-edge, but you're also playing against the risk of the casino going broke.

The statistical math behind risk of ruin calculations is incredibly complicated. While we do utilize concepts such as binomial distributions to double-check certain assumptions, we primarily calculate our risk of ruin by running Monte Carlo simulations. A Monte Carlo simulation is effectively just simulating a random event enough times so that you have an idea of the probability of that event. If you do enough simulations you can get a very accurate estimation of the true odds. This reduces the need for incredibly  complicated math, while also providing us more testing of our actual code (since we run our Monte Carlo simulations against our actual code for the game in question).

So, what odds are we calculating when we do our Monte Carlo simulations? We're not just calculating the odds of the game - we already know that. We are calculating the odds that a player's balance gets above a certain point at any time while continually playing the game and betting the maximum.

So, for example, to set up a Monte Carlo simulation for our single-0 roulette game we create a new player, give them a balance of 0, and have then constantly place a bet of 1 on a single number (which pays 35 to 1). We have them do this 1.5 million times (which is enough for their balance to go irrevocably negative). All the while, we are tracking the maximum value that their balance gets to. We then repeat this entire process 100k times. We can then plot of histogram of the maximum balances of the player, which gives us the effective risk of ruin for various bankrolls:

Risk of Ruin for Single-0 Roulette (player betting 1 on single number)

Bankroll	Risk of Ruin
0	81.605%
1000	17.216%
2000	3.547%
3000	0.75%
4000	0.258%
5000	0.083%
6000	0.025%
7000	0.008%
8000	0.001%

This chart indicates that if a casino wants to have a less than 0.001% risk of ruin, they must have a bankroll of more than 8000x the maximum bet on a single number.

If you run the same simulation on roulette with the player betting on a 1 to 1 bet (ie, betting on red or on even), the bankroll requirement for the house is significantly lower. We find we only need 300x the maximum bet to keep our risk of ruin well below 0.001%.

I found it interesting how much of a difference a 35:1 bet versus a 1:1 bet affects the risk of ruin. If we used our risk of ruin estimation of the 1:1 bet to calculate the bankroll for our 35:1 bets (ie, if we only had 300x the bankroll of the maximum 35:1 bet), then our risk of ruin would be over 50%!

When we launch roulette, we will initially be conservative and will allow bets of up to 10 BTC on the outer bets, and up to 1 BTC on the inner bets.


Exactly! 0.001% is small, but it's not infinitesimal. In order to make our true risk of ruin truly infinitesimal, we have the ability to lower the maximum bet as necessary. We prefer not to rely on this mechanic though, which is why we shoot for a very low risk of ruin without it.


While this is true, we don't rely on this at all when computing our bankroll requirements. Because at any point a player could come and start betting the maximum and playing perfect strategy.

As you can see - we have thought extensively about this problem

That was fun to write, but now it's time to get back to launching roulette!

I would prefer not to rely on a third-party if possible. This may end up being one of the most practical solutions though, given the current feature-set of bitcoind.


Armory does seem quite promising, but I think they still require the entire blockchain to be stored in ram (which makes sense, how else would they be able to quickly get the balance of any address). I also am wary of the security implications of Armory. It definitely doesn't have as many eyes on it as bitcoind itself has, and just because it uses bitcoind for the underlying networking doesn't mean it is fully secure.

Thanks for the advice everyone! I definitely didn't think this feature would have so many pros and cons involved in the decisions we'd have to make! Right now, I think running 2 copies of bitcoind is sounding like the best solution, but I'm not 100% sold yet.