bustabit – The original crash game

[tygeade]

The site is still down I just tried to in and it didn't work, I dont know if it's my network or any other user experiencing the same thing I know the team announced maintenance is it not done with yet.

It is working fine for me, tried it and also since it is a "social" game I have seen other people gamble there as well. While we are here and talking about maintenance and improvements, I would like to also ask about the problem we may face with the "slowness" when we use VPN, it has been like that for years and I understand that there is this thing about not playing with VPN which is why it is not a priority and I get that, it is understandable.

But, are we really going to keep treating VPN as some boogeyman forever and make it very impossible to gamble that way (because of huuuuge lag) or is there even a slight bit of hope about it getting improved? I tried all kinds of VPN under the sun (not specifically for this to be fair) on chrome, and even love using my Opera browser with built-in VPN and all of them gives the same result, you click and takes nearly 3 seconds for it to register. No chance for it to get a look?

[SquallLeonhart]

What if I deposit without opting in, wait 20 minutes without getting a confirmation and change my mind about opting in. Can I at that point opt in and instantly get 99% of the deposited amount in my balance? Or do I have to decide before I make the transaction whether I want to pay the 1% fee or not?

You actually decide after depositing. The way it works is you make a deposit like normal, and then get a notification in bustabit that there's a pending deposit. If you go to the detail page, it shows up as a "pending deposit" and next to that there's a button you can push to have precredited  (and then confirm the fee). At that point the code does a bunch of checks (fee rate, bip125, check unconfirmed parents, checks total site risk, checks if the site has been defrauded before), and if everything is good you get 99% of your money instantly added.

I never tried that as i always wait until my deposit got confirmed then i start to play.

Not like it takes too long neither, this was a valid thing to have years ago in 2017 periods when it took hours upon hours for it to happen but then we end up with something not even close to that anymore, it's very quick.

For example, the last time I deposited it took me about 30 minutes to get it, why spend another extra fee instead of waiting 30 minutes? That doesn't make sense to me, so that's why I do not use that at all. Don't get me wrong, there were a period in bitcoin when you had to wait 8 hours, that's right I have waited 8 hours to get my deposit once, it was early 2018 I think I am not sure, it could be late 2017 as well, and I spent 70 bucks to send it as well, this wasn't for too long but it happened once, so during those times it is obvious that these type of things were very valid features that everyone would love to play and probably did.

[devans]

It is working fine for me, tried it and also since it is a "social" game I have seen other people gamble there as well. While we are here and talking about maintenance and improvements, I would like to also ask about the problem we may face with the "slowness" when we use VPN, it has been like that for years and I understand that there is this thing about not playing with VPN which is why it is not a priority and I get that, it is understandable.

But, are we really going to keep treating VPN as some boogeyman forever and make it very impossible to gamble that way (because of huuuuge lag) or is there even a slight bit of hope about it getting improved? I tried all kinds of VPN under the sun (not specifically for this to be fair) on chrome, and even love using my Opera browser with built-in VPN and all of them gives the same result, you click and takes nearly 3 seconds for it to register. No chance for it to get a look?

Playing bustabit via a VPN feels more laggy because the connection is routed through more computers across the internet and as a result information takes longer to physically travel back and forth between bustabit and your browser. Unfortunately there is nothing bustabit can do about that as it's a limitation of physics itself.

That being said, if you're seeing three seconds of lag with a VPN and the connection is fine without the VPN then my guess is that something is misconfigured in your VPN client or on the VPN provider's end.

[Cuirtswuf]

Can I please withdraw from my account u banned pls

[Lakai01]

Can I please withdraw from my account u banned pls

It has been explained to you a few times that Daniel will not give you support here via the forum and that you should contact him directly via the contact email address. Afaik you were already in contact with him and even received an answer. So I would suggest that you simply ask again via the same way?

[devans]

I have responded to all support requests submitted more than four hours ago (that's when I last checked my inbox). If you sent me a support request before then you will have received a response from me via email. It's worth checking your spam folder as sometimes messages end up there erroneously.

[janggernaut]

I have responded to all support requests submitted more than four hours ago (that's when I last checked my inbox). If you sent me a support request before then you will have received a response from me via email. It's worth checking your spam folder as sometimes messages end up there erroneously.

Do you handle all support ticket on bustabit? Thought there are people who helping you to handle the ticket for faster response to all user who have problem about their account on bustabit (just like guy on above).

[Lakai01]

Do you handle all support ticket on bustabit? Thought there are people who helping you to handle the ticket for faster response to all user who have problem about their account on bustabit (just like guy on above).

Paying extra people to handle support only makes sense if the support volume is relatively high. Especially at Bustadice/Bustabit there are also chats or the possibility to ask questions here in the forum, which surely intercepts many of the requests before they even reach Daniel.

Problems with deposits/payments like in this case have to be solved by Daniel anyway, but I don't think that there are too many.

[devans]

Yeah, I answer all support requests myself. Generally I respond to all messages within 24 hours. In this case the longest response time to their multiple tickets was 7 hours and 2 minutes, which I think is reasonable.

[dezoel]

Yeah, I answer all support requests myself. Generally I respond to all messages within 24 hours. In this case the longest response time to their multiple tickets was 7 hours and 2 minutes, which I think is reasonable.

Lol, why though? I mean you must be making good enough profit to hire someone else for helping you out right? I have zero clue how much you make, it is probably easy to calculate based on what people made and lost since the start of the year on the investment page and then calculate your cut on that. However even without doing that, I assumed that you were making good enough profit to hire some people, not even just one person but more like multiple people to help you out, could be about coding, design, support staff and many things like that.

Why do you end up doing all of that all by yourself without getting any help, is it more about trying to protect the website from someone to come in and change something and ruin it? Or maybe some support staff acting unprofessionally and destroy your reputation? If that is the case we all know you already, I doubt we would put it on you when they do a mistake.

[DarkStar_]

Yeah, I answer all support requests myself. Generally I respond to all messages within 24 hours. In this case the longest response time to their multiple tickets was 7 hours and 2 minutes, which I think is reasonable.

Lol, why though? I mean you must be making good enough profit to hire someone else for helping you out right? I have zero clue how much you make, it is probably easy to calculate based on what people made and lost since the start of the year on the investment page and then calculate your cut on that. However even without doing that, I assumed that you were making good enough profit to hire some people, not even just one person but more like multiple people to help you out, could be about coding, design, support staff and many things like that.

Why do you end up doing all of that all by yourself without getting any help, is it more about trying to protect the website from someone to come in and change something and ruin it? Or maybe some support staff acting unprofessionally and destroy your reputation? If that is the case we all know you already, I doubt we would put it on you when they do a mistake.

It's probably a trust issue and a lack of need. It's definitely hard to find good support people that are knowledgeable about the space (and I'm assuming he doesn't want someone to just read off of a script), and even harder to trust them. If you give too much access, they could theoretically steal lots of money. If you give too little access, you'd end up doing a lot of the work yourself anyway. My guess is that bustabit/bustadice don't end up getting too many support tickets in the first place so it's not a big deal for him to personally handle all of them.

[JollyGood]

What has the amount of profit he might or might not be making got to do with him hiring or not hiring people to help him out?

DarkStar_ has mentioned reasons why Bustabit and other websites might not need or want to have staff handling customer emails, it seems certainly plausible. Even some huge corporations employing hundreds of people inform customers to wait 24/48/72 hours for a reply, some even cite a week. If devans is replying sooner including to someone who has opened multiple tickets in 7 hours then that statistically is excellent and he deserves credit which is why your post baffled me.

After reading your post I thought it was worth a look in to your recent posting history therefore I posted about you for not being the original owner. If I have written anything wrong please free to post in that thread to contest it or correct me but allow devans to keep this thread about Bustabit: https://bitcointalk.org/index.php?topic=5350853.msg57530459#msg57530459

Yeah, I answer all support requests myself. Generally I respond to all messages within 24 hours. In this case the longest response time to their multiple tickets was 7 hours and 2 minutes, which I think is reasonable.

Lol, why though? I mean you must be making good enough profit to hire someone else for helping you out right? I have zero clue how much you make, it is probably easy to calculate based on what people made and lost since the start of the year on the investment page and then calculate your cut on that. However even without doing that, I assumed that you were making good enough profit to hire some people, not even just one person but more like multiple people to help you out, could be about coding, design, support staff and many things like that.

Why do you end up doing all of that all by yourself without getting any help, is it more about trying to protect the website from someone to come in and change something and ruin it? Or maybe some support staff acting unprofessionally and destroy your reputation? If that is the case we all know you already, I doubt we would put it on you when they do a mistake.

[malevolent]

It's probably a trust issue and a lack of need. It's definitely hard to find good support people that are knowledgeable about the space (and I'm assuming he doesn't want someone to just read off of a script), and even harder to trust them. If you give too much access, they could theoretically steal lots of money. If you give too little access, you'd end up doing a lot of the work yourself anyway. My guess is that bustabit/bustadice don't end up getting too many support tickets in the first place so it's not a big deal for him to personally handle all of them.

Given the number of users there could be enough tickets to be an annoyance but finding the right people for customer support in the cryptocurrency space is definitely a problem. The kind of people that will do the job well and can also be trusted will get bored quickly and start looking for other opportunities.

[Lakai01]

Given the number of users there could be enough tickets to be an annoyance but finding the right people for customer support in the cryptocurrency space is definitely a problem. The kind of people that will do the job well and can also be trusted will get bored quickly and start looking for other opportunities.

This is a general issue in software support. It is very difficult to find good people, but the ones you do find are completely underchallenged after six months at the latest and quit again or want more demanding jobs.

However, you will never be able to give a support employee access to funds (FIAT, Bitcoin, ...), the potential that something happens here and you are cheated as an operator is very high. We have now solved this in our company via bots. These can handle about 60% of the requests ("please reset my password", "i don't know how to deposit", ...). About 30% are then handled by level 2 support staff and the rest comes to the owners themselves, especially when it comes to special withdrawal requests or legal threats.

[devans]

Generally speaking, the support requests I could delegate to someone else don't require much time to resolve, and those that do take time to respond to can't be delegated because they require database access to resolve. As a result hiring dedicated customer service representatives hasn't been worth it so far. Besides, I think it's valuable to players that they can immediately and directly get in touch with someone who can help them when they need to

[sharphness]

Hey everyone,

I have some questions about crash games in general and I think this topic is the right place to ask.
Lately I've been wondering about a few things:

Most crash games send game ticks (every 150ms or so) to the client. I'm having a hard time understanding why they do this. Bustabit (and also the old v1 src) does this as well. I know the backend has to loop/tick every 150ms to do cashouts and such, but why would you emit that back to the client. If the client just keeps track of the start time of the current game and updates the counter according to the same formula the backend does then it is always in sync with the backend whatsoever since both sides do a simple subtraction (current time - start time) and pass this onto a function which gives you back the multiplier/point it should be at.

So what is exactly the purpose of the backend emitting the current tick/elapsed time to the client? If the client receives the crash event then it knows the game crashed and can show the crash animation or something similair. I've been looking around in the chrome devtools network tab (filter on WebSockets) and almost every crash gambling site seems to send ticks back to the client, except for one site (https://www.csgoroll.com/) which just sends the start and crash event and nothing else which seems to work fine.

Initially I sent the above (a little adjusted) to Ryan but he forwarded me to this topic so others can also benefit from potential answers

If someone can enlighten me on this specific question I would greatly appreciate it!

- sharpness

[devans]

One reason is indeed ensuring that clients stay in sync. While most devices' clocks don't have much drift, we can't expect every device to be accurate, so it's safer to not entirely rely on the client like that.

But I suppose the bigger reason is simplicity and efficiency. Oftentimes there are lots of cash-outs happening simultaneously and broadcasting each of these events individually isn't fast enough, so bustabit broadcasts cash-out events in batches on every tick instead. We could skip the broadcast if there weren't any cash-outs since the last tick, but it's simpler to just broadcast every tick, regardless of whether it contains cash-outs or not.

Finally, the broadcast tick also serves as a kind of heartbeat, allowing the client to assume that the connection has been lost if they haven't received any events from the server in n seconds.

[sharphness]

One reason is indeed ensuring that clients stay in sync. While most devices' clocks don't have much drift, we can't expect every device to be accurate, so it's safer to not entirely rely on the client like that.

But I suppose the bigger reason is simplicity and efficiency. Oftentimes there are lots of cash-outs happening simultaneously and broadcasting each of these events individually isn't fast enough, so bustabit broadcasts cash-out events in batches on every tick instead. We could skip the broadcast if there weren't any cash-outs since the last tick, but it's simpler to just broadcast every tick, regardless of whether it contains cash-outs or not.

Finally, the broadcast tick also serves as a kind of heartbeat, allowing the client to assume that the connection has been lost if they haven't received any events from the server in n seconds.

Thanks for your answer!
How can the client and server get out of sync though? They only need two variables, the start time of the game and the current time. Both of these can not change since its a simply subtraction.
Even if one of the two variables is subject to change (I dont know how) then I don't see how the game tick of 150ms which gives back the elapsed time can help in correcting this.
I understand emitting back the elapsed time can be used to check if the elapsed time on the client is the same, but as far as I know start time and current time are always the same regardless of where it is called from so there shouldn't be a difference.

About your second point, why is exactly broadcasting cash out events individually not fast enough? If you broadcast them only on ticks wouldn't that result in a delay (not a delay for actually cashing out but a slight delay in updating the bets for other users)? if I cash out at timestamp 3000 and the next tick is at 3150 it will show my cashout of timestamp 3000 'happening' at 3150 for other users.

Lastly the third point you gave, this is the only reason why I could see the purpose of emitting the backend ticks to the client. But lets say a game lasts 3000ms, a user laggs for around 8000ms, when the user resumes it will for instance receive game tick 4000, what useful information can it get from this? I understand it can ensure that the game is alive but it can't conclude from that '4000' that its still the current game or the next one. In my eyes emitting the game id would just be enough if its purpose is only for sending heartbeats.

Perhaps I'm missing something here, which I probably am I guess haha. Just correct me if I'm wrong

[sharphness]

Hey, good question!

So starting from first principles, the server needs to let the client know these events:

a) The game starting
b) When cash outs happen
c) When the game ends


And let's remember, there is a certain amount of time it takes for the server to communicate with the client (latency).


So the most naive solution is simply to broadcast all the events in real time. That will work fine, but the first issue you'll run into is when there's a network connection the client won't (immediately) realize and it'll look like the multiplier is going super high. When the network connection issues resolve, the user will be disappointed to learn that it didn't really go that high.

So we're going to need to broadcast a "heartbeat" (or game tick). Ideally multiple times per second, so if the client doesn't get the heart-beat it knows immediately something is up.

That's going to work fine now, and we're in business. But each message we send/process incurs overhead, and with a lot of events it's going to cause issues on both the server and client. Bustabit v1 was notorious for this. So there's a whole slew of optimizations we can make.

So let's go through a few that bustabit v2 employs:

A) Sends the client the (auto) cashout of the other players. That way the client can "predict" other players cashing out, and there's no need for the server to say the player cashed out at that point. This way the server only tells clients when a player manually cashed out.

B) Batch cash out events. If people cash out at the same time (or close to it), just send it in a big message.

c) Combine heart-beats with cashout events. If the server sends a cashout event, obviously the network connection is fine. No need for a heartbeat in that time.


---

And your question regarding synchronization is a little tricky. So two things to remember: there is always latency between the server and client. It's not possible for the server to tell the client the exact time the game will crash (until it actually crashes) or people would hack the client to easily cheat.

So the client basically has two options. One is to try show the multiplier that is CURRENTLY on the server. The other is to show the multiplier that the player would get if they hit the cashout button. The first solution is better for when you lose (it shows a lot smoother). The second solution is better for when you win (players are a lot less affected by latency. But the multiplier will overshoot the actual crash, i.e. the player will see 1.92x and then see "busted at 1.90x").

So bustabit tries to go more with the first approach. And each heartbeat it tells the client how much time has elapsed, which the client can use to correct its idea of when the game started (i.e. latency is not necessarily constant. It might get better and worse ). You can see how bustabit v1 did this:

https://github.com/kungfuant/webserver/blob/master/client_new/scripts/game-logic/GameEngineStore.js#L192-L195

--

Hope that makes sense!

Hey Ryan, thanks a lot for your answer!

"So bustabit tries to go more with the first approach. And each heartbeat it tells the client how much time has elapsed, which the client can use to correct its idea of when the game started "
Why is it necessary to correct the start time on each heartbeat? How does the start time change? Lets say the client somehow decided the start time to be 5000 but the server actually started at 5001 it will correct this start time on the very first tick it receives, where can it go wrong from there? Why would the client suddenly change the start time?

"So the client basically has two options..." Could you perhaps elaborate more on this? I don't really understand what you ment.

[sharphness]

Why is it necessary to correct the start time on each heartbeat? How does the start time change?

Well, it's not necessary. But it's better to do, and it's easy. So why not?

Basically it handles this situation:
Client receives a "game started" event. Client records the time it got the game started.  5ms later, the server says "the game has been running for 150ms".

With this information, the client can know that the "game started" event was lagged out (e.g. network problems). It can safely update the "game started" time to be 145ms earlier than it previously had it.

"So the client basically has two options..." Could you perhaps elaborate more on this? I don't really understand what you ment.

What part of my explanation didn't you get?

So if I understand correctly the only purpose of the game tick is telling the client the game is still running, esentially a heartbeat.
In case the client does not receive a game tick it can show a 'reconnecting' animation or something similair. I completely understand that and it makes much sense to me. However why is the including elapsed time necessary in this event?

Earlier you said this is used for correcting the start time, why not just send a unix timestamp when game emits the start event? This way desync can never happen since the client has the start time of the game and does not calculate this time itself. If the game start event is emitted 5 second later, the client will still receive the correct unix timestamp when the game started since this does not change in the backend.

So instead of sending: game_tick: 1041, why not send game_tick: true (assuming this is only used as a heartbeat you explained earlier).
I don't see the need of the elapsed time here.