Hi Ryan,
could you please think about (at least temporarily) lowering the withdrawal fee ? In the last days, BTC fee level has been clearly decreased, so I think that 700bits is unnecesarily high fee now. I guess lowering into ~ 400bits would be more than enough. Thanks.
Sorry about that, yeah it definitely should be lower. I made the mistake of hard-coding that value into the configuration file, with the only way of changing it reset the web-server. Which wouldn't be so bad, except I also made the mistake of storing mutes in memory  So I've dropped the withdrawal fee now, but it won't kick in until I reset the webserver (when ever that is). Fortunately in the next release (which is getting very close!) both of those issues are fixed, and withdrawals are going to be way cheaper. Like crazy cheap (thanks to me spending over a month optimizing coin selection and partial batching and what not  ). |
|
|
|
Please tell us what exactly problems by your opinion in our project you think we have?
Because your answers do not contain any specific information.
Your provably fair system:  Has three fatal flaws that I see. 1. It uses md5, this is for all intents and purposes not a cryptographic hash function. This alone would allow the site to easily cheat. It has been 11 years since it has been recommended to not use it. There's absolutely no reason to be using this in 2017, when it entirely defeats the purpose of what you are trying to prove. sha256 is a good alternative. 2. There's no delimiter between your result and seed. In your example you could plausibly claim that the result was "3" or "30" or "302" depending on what suited you. The simplest fix is a delimiter, or explicitly stating you have fixed-length fields. 3. The entire scheme doesn't actually prove the result (e.g. 30 in this case) is drawn fairly. It just proves it was predetermined. You could always pick bad results if you want, and there's no way for us to know. |
|
|
|
Dooglus, were you the first to offer provably fair dice (or do you know who pioneered it?)?
I'm not totally sure, but I think it might have been bitzino as the first provably fair casino? And then satoshi dice (?) had provably fair (on chain) dice. I do believe that dooglus was one who did create the now industry standard of hmac(serverSeed, clientSeed+nonce) though |
|
|
|
|
There's some great responses here, but there's also some potential operational challenges with provably fair.
Pretty much every real-time provably fair system works on the concept of predetermination. You prove you've predetermined something (e.g. send a hash of the server seed) and then derive games from that. But from an operator point of view, this now means you're holding a pretty important secret. Anyone who has the ability to see it will be able to predict future games, and thus cheat the casino. While if you just sourced random number, an employee (or what ever) having read access to anything isn't as huge of a deal.
I do think that provably fair systems will however keep gaining popularity. Once you've enjoyed the peace of mind of being able to actually verify your games, there's no way you'll go back =)
|
|
|
|
|
BTW your provably fair system has 3 different flaws in it, each that would prevent it from being truly provably fair. I'd recommend just going to just-dice.com and stealing theres, which is pretty much an industry standard now and actually robust.
|
|
|
|
|
Congratulations on the release, it's looking good! I look forward to see how things go.
|
|
|
|
Nice work! I'm most impressed by the plinko, that's really well done. It's really cool how it looks like a physics engine, but is totally predetermined too. I found an old script I had, and verified the house edges. If anyone is interested in doing so, here's the js code: let factorial = (() => {
const cache = [];
function f (n) {
if (n == 0 || n == 1)
return 1;
if (cache[n] > 0)
return cache[n];
return cache[n] = f(n-1) * n;
}
return f
})()
function c(n, k) { return factorial(n) / factorial(n - k) / factorial(k) }
function houseEdge(payouts) {
let t = 0;
let p = 0;
for (let i = 0; i < payouts.length; ++i) {
let comb = c(payouts.length-1, i);
t += comb;
p += payouts[i] * comb
}
return 1 - p/t
}
console.log('low', houseEdge([ 10, 3, 1.6, 1.4, 1.1, 1.0, 0.5, 1, 1.1, 1.4, 1.6, 3.0, 10 ]) * 100 , '%')
console.log('medium', houseEdge([ 33, 11, 4, 2, 1.1, 0.6, 0.3, 0.6, 1.1, 2.0, 4.0, 11, 33 ]) * 100 , '%')
console.log('high', houseEdge([ 170, 24, 8.1, 2.0, 0.7, 0.2, 0.2, 0.2, 0.7, 2.0, 8.1, 24, 170 ]) * 100 , '%')
and should get: low 1.0205078125000044 %
medium 1.0107421875000022 %
high 0.8837890624999956 %
|
|
|
|
May i ask what was the largest withdrawal made on your website?
For privacy I'd prefer to not be too specific, but there have been >200 btc withdrawals (that were processed instantly) I see people with 80+ btc on their balance (net profit) in the leaderboard. Wondering why are they still holding and if it's even real  You can sort and see the biggest winners by net profit: https://www.bustabit.com/leaderboard?by=net_descHowever, this is *not* their balance. It's just their profit. Profit isn't affected by deposits or withdrawals 1. Do you ask for any verifications when withdrawing the large sums?
I never have once asked for any form of verification in the past, but I guess it's possible I might need to verify something in the future depending on circumstances. But in general there's nothing. 2. Am i able to have multiple accounts to test different strategies?
Yeah, that's fine |
|
|
|
Re: Withdrawals. There's no restriction or intentional delay. Actually when I see large players or people with large balances, I make sure there's a lot of money in the hot wallet to have withdrawals instant. I can't guarantee anything, but I think I've been doing a pretty good job at it. I think it's been >6 months since the last time the hot wallet was empty and couldn't immediately process withdrawals I hope that's true. At the moment i'm waiting for my withdrawal for over an hour already and it still has 0 confirmations.
If your withdrawal doesn't get confirmed within a block, just use bustabit.com/support and ask for a fee bump, and I can prioritize it free of charge. Normally this isn't required, and I'm looking to automate this in the future. It's a really tough balance trying to avoid overpaying for transactions and underpaying =) But fortunately the next release will be a lot better at this, and there will be two different withdrawal speeds to strike a better balance |
|
|
|
We had a pretty nice win last night by: mrbeast6000. He *almost* got to a 100 bitcoin profit, but hit a bit of bad luck and finished the night 86 bitcoin up! |
|
|
|
|
Get the transaction id, and enter it into estimatefee.com it'll tell you the estimated amount of blocks (with 50% probability) and if you multiply that by 10 you'll have an estimate in minutes.
But since it's a Sunday now, all the backlog should be clearing out
|
|
|
|
prov fair processed by Dexon and approval of the process by Ryan means good news for the site.
Please note that I'm not approving (or disapproving) of the process. I'm merely quoting it so people can see what it originally was with assurances that it doesn't change. I personally haven't verified any games so I can not make any statements either way. |
|
|
|
Quoting to prevent changes. Also archived at: http://archive.is/I9E2lAlso confirming that block 482030 hasn't yet been mined Disclamer: I was hired by winxrp.com to make this seeding event and therefor set up the provably fair on the game. I will not be part of the team that manage this site. This will reuse the idea posted by Ryan and used for Bustabit. - A chain of 10 million sha256 hashes was generated, starting with a Server Secret that has been repeatedly fed the output of sha256 hash back into itself 10 million times.
The final hash in the chain is: d760e15075a3c29537ac2159cf15aec017ca039b8b114180d02e67040dd6b65e, by publicizing it here we are preventing any ability to pick an alternate sha256 chain. - winxrp will play through that chain of hashes, in reverse order, and use the hashes to determine the crash point.
- To avoid criticism that the Server Secret used in step 1 was carefully chosen to generate lots of "bad" crash points, each hash in the chain will be salted with a client seed, which we have no control of.
The client seed will be the block hash of a Bitcoin block that hasn't yet been mined: block 482030.
The reference code (javascript) is as follows: The method to create the hash chain is simply sha256: function genGameHash(serverSeed) {
return crypto.createHash('sha256').update(serverSeed).digest('hex');
}The method to convert a game hash, mix it with the picked client seed to a money pot multiplier: function crashPointFromHash(serverSeed, clientSeed) {
function divisible(hash, mod) {
// We will read in 4 hex at a time, but the first chunk might be a bit smaller
// So ABCDEFGHIJ should be chunked like AB CDEF GHIJ
var val = 0;
var o = hash.length % 4;
for (var i = o > 0 ? o - 4 : 0; i < hash.length; i += 4) {
val = ((val << 16) + parseInt(hash.substring(i, i+4), 16)) % mod;
}
return val === 0;
}
var hash = crypto.createHmac('sha256', serverSeed).update(clientSeed).digest('hex');
/* In 1 of 101 games the game crashes instantly. */
if (divisible(hash, 101))
return 0;
/* Use the most significant 52-bit from the hash
to calculate the crash point */
var h = parseInt(hash.slice(0,52/4),16);
var e = Math.pow(2,52);
return Math.floor((100 * e - h) / (e - h));
}The chain could be generated with code such as: var serverSecret = 'If you knew this, you could steal all my money';
var clientSeed = '0000examplehash';
var gamesToGenerate = 1e7;
var serverSeed = serverSecret;
for (var game = gamesToGenerate; game > 0; --game) {
serverSeed = genGameHash(serverSeed);
console.log('Game ' + game + ' has a crash point of ' + (crashPointFromHash(serverSeed, clientSeed) / 100).toFixed(2) +'x', '\t\tHash: ' + serverSeed);
}
var terminatingHash = genGameHash(serverSeed);
console.log('The final hash is: ', terminatingHash); Using our chosen starting serverSeed, the hash terminating the chain is d760e15075a3c29537ac2159cf15aec017ca039b8b114180d02e67040dd6b65e. That is to say, the first game's hash played under the new provably fair scheme, when hashed will be d760e15075a3c29537ac2159cf15aec017ca039b8b114180d02e67040dd6b65e. |
|
|
|
Last night about~2 dozen people got tricked into running malware. Please, please don't ever run programs by people, regardless of who they are. In the interest of education, here is a youtube video SPREADING MALWARE, DON'T BELIEVE IThttps://www.youtube.com/watch?v=X9BlkTI1TDYThis isn't specific to bustabit, but: *) If someone tries to get you to run an executable, they're probably scamming you *) If someone does have an exploit/hack or what ever, there's no way they would share it. They would milk it for all it's worth, and try keep it as low-key as possible |
|
|
|
I've visited this site, but i don't understand how to play it and how i can get a chance to win and not lose much. I really still don't understand, this site is very interesting to try and it seems i have to quickly understand and winning in here.
Basically the goal is to "Cash out" before the bust. If you do so, you get the multiplier you cashed at. It looks a bit intimidating at the start, but it's really quite simple |
|
|
|
as old Moneypot owner and new Moneypot owners dont want to answer this simple question and are telling me that our Jackpot was an illusion I will open soon open a scam accusation because they cheated our customers
Ummm ok? Each bet your site placed on MoneyPot was completely atomic and the full bet details (possible payouts and probabilities) can be looked up on the page by entering in the bet id. Furthermore, each bet is provably fair which allows you to verify the bet hits the correct payout you specified. The very fact your site did have some large winners (60+ bitcoin?) makes it pretty evident that things were working as intended. The entire jackpot on your site was just an illusion. Not in the sense that it was unwinnable (it was), but in the sense there was never any money put aside exclusively for it. Your site just had gave users a smaller-and-smaller chance of winning a bigger-and-bigger jackpot, which gave the impression of a cumulative jackpot. But when your site shut down (or MoneyPot changed hangs), there was no "jackpot" money per se. So the idea that you wait almost 2 years, and now start accusing me of stealing an illusionary jackpot would be hilarious if it wasn't so sad. I really have no intentions of interacting with you further, so I'll reference this post in my feedback to you, incase someone is wondering why I'm ignoring your frivolous claims. |
|
|
|
Funnily enough, I just added this guy to my ignore list. But it doesn't work on top-level topics, so I'll indulge him for one last time. please take the Poll serious because it will be easy to see who is serious because it is a simple math question
The only reason you think it's a simple maths question is because you don't understand the problem domain. Multi-outcome bets like your site did (e.g. having a win, lose and jackpot) are sufficiently complex that I was never able to even find an analytical solution. If you want to learn how to solve it, look at: https://math.stackexchange.com/questions/662104/kelly-criterion-with-more-than-two-outcomesThe first step however is to normalize the bet into how investors see it (e.g. how much they will make or lose after commission for each outcome). One you have it in the format: [Probability, ProfitIfEventOccurs] for each outcome, you can run the kelly formula (see the stackexchange question) that will tell you how much of your bankroll to risk (again from investors point of view). Once you've done this, you can map it back onto the original bet to determine if it's "kelly compliant" or not. If you want to do it in a simpler way, you can establish a lower-bound if you wanted by converting your multiple outcome bet into a binary one. The key is preserving both the house edge and the largest payout. Then you need to normalize it from investors point of view (e.g. by looking it after commissions) while keeping it binary, where one of the options is "lose entire wager". After that, once you have the house edge (say E) it means that to be kelly compliant investors should never risk more than E*bankrollSize. Which means that you have established a lower-bound of that the highest payout in your game should allow gamblers can be allowed to win E*bankrollSize-comission. |
|
|
|
you even admitting that you dont remember and saying the Jackpot amount was an illusion is telling me that you are same clown as Dogedigital and even worse cause it was never an illusion and proof is that many hit the Jackpot with the same chance if it was for 1 bit or 1000 bits and the chance was always same but the amount of the Jackpot was different according to his wager amount.
The idea that there was a cumulative jackpot was an illusion. There was never funds set aside for that, just that each bet had a smaller-and-smaller chance of winning a bigger-and-bigger payout. From an EV perspective, it was always constant regardless the jackpot size or bet size. Each bet was always kelly-compliant so there was no need to put money aside for the jackpot. The payout just kept growing (with a smaller chance of winning) and was called a "jackpot" but was completely a arbitrary number, just an amount that could be won. You could make it anything (as long as the bet stayed kelly-compliant) but if it is as you are describing it now then the players were fooled and had no chance to hit the Jackpot! be assured that we never would accept this kind of Jackpot because then we would cheat the players. but as you are saying/explaining it means you wanted to cheat the players!
Players were not cheated, they had a chance of hitting the jackpot. I was giving numbers for illustration. If you want to know the actual figures, go and look up one of the old best you made. The probability of hitting the jackpot is encoded in the bet as a payout. if it was the case then you or the new owners changed the chance of hitting the jackpot without telling us and this would be a CHEAT! the chance to hit the jackpot was clearly explained in our FAQs and ABOUT and we never lied to our players! we had whales playing and they easily could hit the 5-8 BTC Jackpot and you are telling me that the Jackpot amount never existed?  ?? what if Molloype hit the Jackpot are you telling me he would not be paid cause the Jackpot amount did not exist? or are you telling him right now that he never had a chance to hit this Jackpot? ?? because you or the new owner coded our Jackpot so it could not be hit? this STINKS! if you like or not! Again, each bet had a certain chance of hitting the jackpot... It was completely provably fair, you can just look at the bet. regarding apologizing it is your turn to apologize!
JPR Jackpot 1 in a million chance LOOOOOOOOOOOOOOOOOOOOOOL you Moron
Welcome to my ignore list. This will be the last time I see or reply to a message of yours. |
|
|
|
Holy shit. JackpotRacer you're a certifiable idiot. I am asking questions to get straight forward answers thats all. as long you guys are not telling lies and not bullshitting I am fine and that I am unpleasant thats fine for me because I see the truth hurts! I also know that you are smart enough to know that I am right with what I am saying and you often confirming it and then sometimes delete it  I've deleted some of my posts in the past because I was too much of an asshole, which I tend to always regret. But don't worry, I've carefully reviewed the tone of this one to make sure I wouldn't say anything I could possibly regret. now lets see if you remember our racer game with the unique Jackpot in those times. you called it "Ingenious" and we were very proud to hear it from you the MP owner. as I understood you also tried to code it for MP and new MP owners not long ago completed the coding and added it to their API
I do not remember any of these events. But for the record I have not been involved in MP in any capacity ever since I sold it. However the JPR game just used the standard MP api which was there from day 1. lets say in December 2015 when you sold MP the JP was about 5 BTC. did you gave those 5 BTC on to the new owner so in case the JP is hit they could pay it out? I mean they would need to pay it even out of their own pocket if the JP would have been hit after the sale.
For a moment I was a bit confused. I thought you must have bought the JPR account considering you don't even know how your own app worked. But then it wouldn't explain how two different people could be so annoying, so I guess the simple explanation is you're just a moron who literally forgot how his own app worked. The jackpot funds never exited. It was an illusion. Each bet had 3 outcomes: WIN (normal), LOSE, HIT JACKPOT. The probabilities and payouts were designed such that it was always +EV and +EBG from MP's perspective. (e.g. a player might make a bet that has a 49% chance of making 0.1 BTC, ~51% of 0.1 BTC, and a 1 in million chance of hitting a 10 BTC jackpot). Then to make the "JACKPOT" win part look more impressive, your app would continually increase the size of the jackpot (while decreasing the probability of winning it) to maintain a neutral EV (which iirc was around ~0.01x of what the person wagered). If you don't believe me, look up the bet id of one of the old bets and look at the multiple outcomes and probabilities and EV. So next time you want to imply I stole money, you should do so for money that actually existed. If you feel like apologizing, that would be appreciated. I hope this helped to understand my question before
It indeed did. |
|
|
|
|
Show Posts
