Anyone knows what is APY from bankroll investing after the change to the commission ?
You can piece it together from https://dicesites.com/bustabitHard to predict exactly, but I divested most of my funds, as the returns were pretty low (and put some more in bustadice which had higher returns). Although there can still be some potential. Like on 2022-1-1 I invested 1.03 BTC into the bankroll (all I had in my account at the time) as a whale was playing and was just annihilating the site. Whales often have a tendency to keep gambling until the odds catch up with them, and now, a week later, that 1.03 BTC is worth 1.16 BTC. But that's no where near typical returns, and was really just because I was lucky and timed the investment after the whale had won so much money under the assumption that he'd probably return his winnings back into the site. But yeah, bustabit investing is nothing like the early days  |
|
|
|
|
I've seen several things like this, where scammer A is posturing as a lucrative scam target. Then scammer B comes in, in this case would create an account like iiiily and try claim the money. Then scammer A would then lead B on and get him to do something stupid (either send some money, or often these type of scams involve asking for screensharing).
The real question though, is it morally ok to scam a scammer?
|
|
|
|
Daniel you're being fucking annoying now
"He clearly has an unhealthy relationship with gambling, I'm just being ethical" Nah you're being annoying taking my entertainment away.
How exactly do you want me to prove I'm fine with gambling? Do you want to get in a call? Do you want to see my bank statements to see that I'm financially sound? Because I can do both for you right now buddy
How can you base your speculation of my relationship with gambling solely on me asking to be unbanned?
Just to be clear, I'm not Daniel nor represent bustabit in any shape or form. I know nothing of your situation other than what was posted in this forum, however, I do know enough to know that generally when someone takes gambling from a fun activity to thinking they can beat a luck-based game it's not particularly healthy. Out of curiosity, was your gambling ban self-requested? As it seems like a reasonably common pattern at a casinos, a person requests a permanent self-exclusion due to their gambling problem, then later want to gamble and then tries to reverse it by trying to raise as much problems as possible. No sane casino will ever reverse a permanent self-exclusion because besides being unethical, if the person then does come and lose money they start bitching about how they should be reimbursed for their loss because the casino didn't honor their self-exclusion and took advantage of their known gambling problem etc. |
|
|
|
Buddy its not your fault, just Dan beginning his project of soon exit-scamming but before that he need get rip of his projects, so there will be less noise, if you want know more, leave your telegram or discord, i will explain with proofs of that, i was shocked too.
The guy clearly has an unhealthy relationship with gambling if for no other reason than his last posts are him saying he thinks he can beat a luck-based game... If you think a person like that getting restricted from gambling on a casino is an early sign of an exit-scam -- and not a sign of a casino trying to act ethically and not take advantage of someone with a problem -- I really don't know what to tell you. |
|
|
|
You haven't really done a good job of explaining what's happening. I don't know your situation, but I'm going to go out on a limb: * If you can't bet, but can withdraw: You're probably banned for being obnoxious, underage, self-requested gambling ban, or something like that etc. * If you can't bet and can't withdraw: Your account is probably compromised. If you're the legitimate owner, open a support ticket with Daniel so you can find out what's happening and he can facilitate returning the account to your exclusive control. But either way, you should use https://www.bustabit.com/help/contact as no one has any idea what's happening with your account and we can only speculate. If it's actually your account, you really don't have anything to worry about, Daniel handles millions of dollars a day and I've never seen a complaint against him that gave me pause |
|
|
|
Yeah, what's up with the "license"? https://archive.is/nyqw9I'm no expert, but it'd assume if you were going to photoshop'd a fake license, you'd at least pick a country that offers a similar sort of license >< |
|
|
|
|
I'm also going to go out on a limb and say the Kelly criterion isn't nearly as important as people think. Although it's important (or a casino operator) to really understand it and the whole concept of "expected bankroll growth" (which the kelly maximizes) and how that can even be negative (!?!!).
But the reason it's not as important as it might seem, is because the casino isn't the one picking bet sizes. They can just put limits, which will and can drive players to other casinos. For a small and bankroll-constrained casino, it's probably not too unreasonable to risk up to twice the kelly optimal (at the expensive of _stupid_ variance). A big established casino probably doesn't even need or want the stress of running a full kelly (which is actually pretty extreme).
And you also can't be complacent, I remember when the (late) moneypot went to 3.33x kelly, I wrote them a simulation showing they were negative-expected-bankroll growth and a whale would most likely bankrupt them. They ignored me and thought it was too "theoretical". Couple months later they were actually bankrupt...
|
|
|
|
But the tldr is that a casino has to manage a who set of trade-offs. A non-comprehensive list: * Bigger bets result in bigger EV * Bigger max-profits result in higher risks * There are risks that aren't represented (e.g. the site gets hacked and the hacker pretends to be a gambler) so higher limits make it easier to abuse * Bigger bets/max-profits allow the game to appeal to more people (i.e. whales and newly-created whales) * Big bets are great for marketing (who doesn't like a whale show!) for example, there's a big site that has a crash game with a 1% house edge, and they auto-cashout users at a win of 0.75% of their bankroll , so this is the max win.
I assume you're talking about bustabit? If so, it's going to be a bit different due to the multiplayer aspect. Namely it needs to have a per-round max-profit (to protect the casino) and then a per-bet max-profit (so a single whale can't win almost all the per-round max-profit and ruin the fun for everyone). -- But if you're interested in bankroll management, the goto resource would be: https://en.wikipedia.org/wiki/Kelly_criterionalthough its a bit intimidating at first |
|
|
|
|
The two questions I always have for people selling strategies / bots / etc. is
1. Can you replicate it on a fresh new account. And announce the account before you start. That way we know that you don't play on N accounts, and then simply announce the best result.
2. Why don't you just instead use your own strategy? Why does it make more sense going through all the effort of selling it, when you could simply use it
|
|
|
|
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.
yeah However why is the including elapsed time necessary in this event?
It's not necessary. But it's very useful. Another good use of the elapsed time, imagine there's a big lag spike (actually extremely common on 3g) of a few seconds. The "first" heart-beats are pretty much useless, as you're just catching up. The elapsed time lets you know this too. 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 would be nice, except it's not practical at all. It would require all clients to have to correct system time, and to a very high degree of accuracy (milliseconds..). It's hard enough in a cluster of machines to get them all to have a reasonably accurate clock, let alone in a situation with random people around the world playing on random ass devices. You could probably do some hybrid-approach where the client detects if it has a correct system time (probably use a low-latency cloudflare worker) and uses the absolute-time the server provides iff it has the correct system time (otherwise approximates it, as best it could). |
|
|
|
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? |
|
|
|
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! |
|
|
|
I don't understand why many sites here on forum mention "instant deposit" and then like on any other sites I see this message on deposit page "Only send BTC to this address, 2 confirmations required."
Is it instant or does it require 2 confirmations which isn't instant for sure?
Some sites have "instant deposits" in the sense they will sometimes credit your deposit instantly subject to certain risk factors (e.g. high fee, established player, no-rbf). And of course there's also sites sometimes blindly copy the wording of their competitors even when it no longer makes sense  |
|
|
|
Hence, isnt this considered a scam? What can be done about it, can we report them on bitcointalk? Never wouldi have gone on their site if i had known about their real house edge.
I don't think it's a scam, I have never seen them outright lie about the house-edge (if so, I would've called them out on it). But I do think it's a bit unethical to not be disclosing your house edge (especially when asked!) especially if you clone a game you'd generally think you'd offer the same odds. A good example of this is the even the author of the roobet crash verifier thought they were using the same procedure as bustabit (v1) and didn't account for the 1-in-20 instant crash they snuck in. I got nothing against high house edges, just think you should be straight forward about it as it's something any reasonable person would want to know. |
|
|
|
I think the house edge is even worse than speculated. They basically copied bustabit's (old) dynamic house edge scheme, which was designed to scale a house edge of between 0-1%. The reason bustabit did that, is they had a bonus system that gave out bonuses for cashing out after other people. So the earlier you cashed out, the less house edge and the later you cashed out, the higher house edge (up to a max of 1%). But roobet removed bustabit's bonus system, and then slapped on a 1-in-20 chance of 1x. So the net result is a house edge that scales between 5% and 6% depending how you play. We can verify this by simulate playing a million games of flat betting 2x: const gamesToPlay = 1000000;
let bankroll = 0;
for (let i = 0; i < gamesToPlay; i++) {
let n = crashPointFromHash(generateHash(i.toString()));
if (n >= 2) {
bankroll++;
} else {
bankroll--;
}
}
I'm using a deterministic hash, so people can reproduce my results. If you flat bet a million times at 2x, you would lose 54800*bet .... which is a house edge of 5.48%. If you cash out later (than 2x) you'd expect to see a higher house edge (which will max out at 6%) |
|
|
|
The issue is caused by roobet took bustabit's provably fair scheme, and then added this to their crashPointFromHash code: if (divisible(hash, 20)) {
return 1;
}
which causes an extra 1 in 20 games be 1x. The verification code that's being used is unaware of that change, so it's showing what the game results were on bustabit. It's not exactly cheating, because they never claimed to not have it (i.e. pretend they have a 1% house edge). But it's also disappointing they don't publish the actual house edge anywhere... (and don't even give it when directly asked) |
|
|
|
Bustadice has a house edge of 1.0%, therefore the game cannot be beaten long-term mathematically, nor should it be relied on as a source of income. No matter what script or "system" you utilize, all players should expect to lose $1 for every $100 in wagers placed. Caveat emptor applies here.
That's true, although the one thing I'd add is you can create strategies in dice to lower the expected wager volume which lower the "effective" house edge. i.e. If you compare "1 BTC @ 2x" with "0.5 BTC @ 3x; stop if win, if lose bet: 0.5 @ 4x" Both strategies have the same outcome (you either make 1 btc in profit, or lose 1 btc) but the later strategy has a higher expected value. As Dooglus once said, "you can't be good at dice, but you can be bad at it" |
|
|
|
Is the site down RN? I am unable to login.
Yup Daniel said he's working on it now, sounds like it'll be a couple hours or something |
|
|
|
If you can get away with it, that is. Which won't be the case with most people starting their own site if they don't have a very high reputation/social proof/etc.
(As a site operator) the nice thing about a dynamic commission is you can use it to incentivize people to invest when you need investors too. Secondly I keep thinking why do people actually do these things?
Given enough people and time, pretty much every thing that can happen, will happen. I'm kind of more surprised that he's not grateful that he will not lose access to his funds, just needs to wait 2-weeks for his 2fa email to be reset. I'm digressing a little, but something similar happened to me, mostly due to a (now fixed) design flaw in blockstreams greenaddress wallet where they required 2fa which I used Google Google authenticator for. Google authenticator has no way to export the secret, and greenaddress had no way to even request a totp reset. To recover my funds, I made a very very low intensity brute force script (each attempt has a 1 in a million chance). Out of spite, they manually blacklisted my funds (0.1 BTC) and have held it ever since. I think if you compare how Daniel is handling it, compared to blockstream ... you'd see Daniel is pretty damn professional |
|
|
|
|
Show Posts
