Wow, wtf. I've never seen anything like that. That's retardedly unfair. It wouldn't even stop abuse, just a way to screw legit gamblers.

When ever I see stuff like this, I always wonder if they're scummy or stupid, but I guess either way it's not somewhere you can imagine wanting to play :/

Oh wow, I missed the drama of Game-Protect getting banned. I was starting to wonder every gambling thread was not getting derailed into a bitch-fight about her scam and "casino licensing" etc.

It goes into the bankroll. The bankroll is owned by people who have "invested" in it (everyone has a stake, which represents what % of the bankroll they own). Bustabit itself charges 50% of all the bankroll-profits when ever it exceeds the historical "all time high" profit.


So a worked example:

 Say the bankroll is 1000 BTC. Then someone bets and wins 10 BTC.  They win from the bankroll, so the bankroll is 990 BTC. All investors stake remains the same. Now someone bets and loses 100 BTC. The bankroll would normally go: 990 + 100  = 1090 BTC. Except bustabit (aka Daniel) will want his cut. So he'd take 50% of the amount it's exceeded the historical highest profit. So in this case it'd be 50% of 90 BTC  = 45 BTC. So the bankroll will actually increase by 100 - 45 = 55 BTC, i.e. the new bankroll will be 990 + 45 = 1035 BTC.


So in summary:

When you invest or divest you get a % ownership of the bankroll (which adjusts other peoples % ownership). When players win, they win from the bankroll. When players lose, they lose to the bankroll (and bustabit's commission).


People only need a license if they use bustabit's actual code. Bustabit made the old version opensource under a restrictive license that requires you to keep any changes you make also open source, and had an option to buy a license that allowed you to make changes without needing to make them also opensource. Many people however just use code and don't abide by the license, or use the actual bustabit code but try pretend they're not.

It was maybe a mistake, but bustabit never tried to control the game-concept (i.e. there's no patents or anything like that), just a copyright on the actual code that bustabit uses. Think something like lord-of-the-rings. If you want to write a book about elves and orcs and shit you don't need permission/license from Tolkien's estate. But if you want to actually use his words, you do.

Well, ignoring my earlier concerns -- it's not. Your system is asking people to commit to a client seed before you commit to a server-seed.



Stuff like this just makes me wonder if you have no idea what you're talking about, malicious, or both.

They don't really deserve a second chance, and it doesn't address the fundamental problem. They were openly scamming people, and most likely still are (just yesterday someone reported getting 84 losses in a row when trying to get 2x, which is for all intents and purposes impossible (1 in 0.505^84) if the site was legitimate.

FWIW I don't even think they implemented the new provably fair system properly -- but I really don't want to waste any more of my time on a thinly veiled scam.

If there was just an accidental flaw in the provably fair, and you fixed it -- it would be no deal. But there is a large amount of evidence that not only is your provably fair flaw, you were also actively cheating people.  Unless you can somehow managed to provide convincing evidence that you were not in fact previously scamming people with rigged games (or provide a realistic explanation to why it won't happen again, like: our co-founder thought it was a good idea to rig games but we have since fired him) , I see no reason to remove my negative trust. A fixed provably fair system will just allow people to properly verify games, but it still won't prevent you cheating.

Investor returns are 13% (?) higher than expected, and have been strong enough that long-term investors have been able withdraw more than they put in while keeping a balance higher than what they put in (!).


While that certainly doesn't prove anything (after all, if he stole $1000 from investors it would barely be a rounding error) and there's probably ways to fudge the stats like pretending there's less wagered than there really is (although that's tricky, because all bets are broadcasted to all players). Anyway, it does seem like a reasonable concern, so I'd suggest you shouldn't invest (or divest if you have) but it's a bit of a leap to just make random accusation without even circumstantial evidence.

So it's possible to use a very carefully crafted martingale strategy to make it less unfavorable for the player to achieve a certain result. (e.g. instead of a 49.5% chance of doubling, you can lift it to a possible max of 49.65%). The way this works is by lowering your expected wager amount, while keeping aiming at your desired profit.


Although, I think you can invert this -- and say: Why does the casino punish users for using the normal UI for placing a bet? If it's possible to use a carefully crafted strategy to double your money with 49.65% chance, why if I use the normal bet form do I only get a 49.5% chance?


(I guess this comes down to my argument that flat-house-edges for different payouts are easy to understand but the wrong thing to do for players. Both my previous projects bustabit(v1) and moneypot didn't use fixed house edges, but I think it was misunderstood and under appreciated  )

I think you'll find all your bets are using the same client-seed, which has a trailing space. Most likely you accidentally entered this. Interestingly because your nonce is: 306 it makes it computationally impossible that bustadice picked a malicious sever-seed in the first place.

That said, bustadice should either not allow or warn users when they have confusing client seeds (e.g. leading, trailing, double spaces, weird unicode...) and prevent this confusion from happening in the first place.

I doubt the OP is going to mind being getting paid 50 BTC per week. But it's a pretty weird term, I think. I guess I can see some utility if they want to put some spending-limit policies on their cold wallet, or something like that.


I think bitcasino.io is handling this pretty terribly, though. I used to (few years ago) run bustabit, and handled many multi-million dollar wins -- and really the secret is giving issues like this absolute top priority. If a large-winner waited more than 10 minutes on me (which did happen a couple times, I admit), I considered that I failed at my job. But generally (90% of the time, I had all the funds hot and ready to go so that even a multi-million dollar win could be instantly withdrawn).

And the reason is logical, the player could've had an amazing experience and been a raving fan-for-life, but instead they've now been given a pretty shitty/mixed experience even if the withdrawal is processed:


I remember often I'd have players that told me they won large sums of money from other casinos that took them a week+ to pay them, and even though they won so much money (from the casino) they had such a bad/nervous/anxious experience they refuse to even come back. Kind of blows my mind that casinos are still doing it the old-school ("please nervously twiddle your thumbs while we decided what to do") way when it's so counter-productive for all parties.

Bitstarz is one of the shadiest casinos out there. It's pretty much their  entire MO is to steal players balances, and when they don't, they like to try to (e.g. weaponizing their KYC for the sole purpose of making sure people don't withdraw or get frustrated and gamble away their money.). They seem to be well promoted because they are able to offer a super generous affiliate program, so the 100000 "casino review" (affiliate farm) sites out there love promoting it.  

The good news is bitstarz tries to keep a thin veil of legitimacy, so you can use that in your interest. Link your story to their bitcointalk feedback, contact all the review sites, their licensing etc. And in the mean time do not gamble or lose your money, as it's a process that (intentionally) takes a long time. Generally if you're annoying enough, they would rather just give your money, they prefer to steal from people who keep quiet.


And for next time, try play at a casino listed here: https://cryptogambling.org/ (it's not a perfect list, but it's by far the best one I've seen out there)

You can derive/guess from historical stats: https://dicesites.com/bustabit although it'll massively be affected by variance (i.e. it's not unusual for someone to win or lose 100+ BTC).

But realistically if your time frame isn't measured in months or years, it's a pretty bad investment.

I saw he ended up +213 BTC, and then posted something along the lines that having so much money is too much pressure and he doesn't deserve to be rich  -- so he plans on killing himself and leaving the money to his family. He then deleted his account after that.

I hope he's alright, seems like he's a bit overwhelmed with his win :/

So the first thing to note is that a final outcome of 123 means a multiplier of 1.23x. So `123 / crash` is easier to reason about if you think of it more like `1.23/crash` in maths terms. And as we already discussed, `crash` is evenly distributed between 0 and 1. So if you wanted to simply turn it into a multiplier you'd do:   `100 / crash`  ... but no casino is going to do that, as they need a house edge for themselves. I know bustabit effectively uses `99 / crash` to make a house edge of 1%, but rocketpot is using `97 / crash` which is going to result in a significantly higher edge (of which some will be used to fund the bonuses/jackpots/other benefit thats bustabit might not have).

I think I'm the original author of this, as it appears to be copied from bustabit. I was just trying to convert a sha256 hash into a number between 0 and 1 (and then turn that into a multiplier). The most obvious and correct way to do this would be simply get the hash (as a number) and then divide by 2^256. But as the original bustabit was written in javascript (both the server and client), I wanted to approximate that in a simple way. Javascript's only number type was a 64 bit floating point, which means it can only represent integers accurately up to 2^53 - 1. So the cleanest number less than that is 2^52, which is the max number if you read the 13 hex characters of a hash.

So basically the logic is "read the first 13 hex characters from a hash, parse as a number, divide by 2^52" and now you have a number scaled between 0 and 1.

But it's really just an artifacts of the limitations I was working with at the time (e.g. python if i was working in python, I would've just done divided the whole thing. Or if i was working with a language with proper 64 bit numbers, would've done that, etc. )

Quoting. And saved to archive.is: http://archive.is/lffmw

Also confirming that the current best bitcoin block is: 631013 and thus 631111 has not yet been mined.

I'm excited to see your new game!

Sure, I get that. But in practice is sort of is.


I guess you could build some sort of "multi_index" for the txoutset, which allows lookup via (txid), but also via (script).  Then merkelize that shit, and make it part of the block commitment.


Now that would be bad-ass. But I have a feeling we'll never see that . While you sort of more or less get that out-of-the-box with something like ethereum (although you obviously get a ton of disadvantages from their account system too)

I was thinking even with an account system, you'd still generally want to use it like bitcoin (e.g. a transaction could have multiple outputs, and you try not to reuse accounts). I guess major property I like of account based systems is say you have a sync'd node, you can naturally very easily import private keys without a rescan. While I guess it's never an "essential" operation, in practice I think it's very very very useful. Even if bitcoin gets a utxo set commitment (Which I think it could very much benefit from), you'd still never realistically see a "address index commitment" or the sorts.

I don't see how that matters -- the consensus rule would be "the same txid can't ever be included twice" and "a transaction can't ever be included in a block greater than its max-height". And nodes use the "max-height" to determine when they think is safe to prune (but there is no obligation to do so) but they can be stupidly conservative (e.g. only prune week old stuff). This is pretty much the same in bitcoin, where pruning isn't "re-org safe" but in practice it doesn't matter


Don't really know anything about this, but I wouldn't have thought it's a big deal.


Agree this kind of sucks.



Yeah, there's some nice properties of a nonce, but I don't really get how you can prune efficiently which seems suboptimal. I'm kind of in the camp that running a non-pruned node is massive overkill, and the IBD is nuts and safe people aren't going to go through it. So I kind of like the "account system" style as they seem to naturally support light-clients a lot better. Although I can't say it's something I care that much or think very much about

@ondrere sounds like your describing an "account system" (in contrast to a utxo system) which is what some currencies like ethereum use. It has some pretty big pros and cons, that have been discussed a lot.


I think there's an easy fix, that I haven't seen anyone do. Do you see the problem with it?

Nodes maintain a set of spent txids, and thus refuse to accept the same transaction twice. This "spent txid" set would also be prunable, because each transaction would contain a "max block height" (thus the transaction itself expires). So you only need to keep the "spent txid" until it's unspendable anyway.