bustabit.com -- The Social Gambling Game

[Muttley]

so is this website ok and legit still?? what happened to the original moneypot?

Yes, it is legit (until now). No serious issues.

[RHavar]

Ryan can you please explain if you have time how would you use kelly criterion in order to calculate the max bet?

Doing it perfectly in a game like bustabit would be quite challenging, as we have a dynamic house edge (between 0 and ~0.99%). Basically you'd have to wait until everyone bet, then solve for "Point that my loss would be: HOUSE_EDGE_AT_THAT_POINT * MyBankroll" (as equation I'd only know how to solve numerically)  and probably adjust that after each person cashout.

Or you could just estimate the average house edge at ~0.33% and make the make max profit  = 0.33% * bankroll

[RHavar]

This is just a heads up. I've been waiting for more then 2.5 hours for a withdraw to confirm. I'm posting the txid to see if anybody can see why its taking so long.

txid: e5a361b7da376bcf7f9575e1a16414faac6261f850740dabf9d9f6c0f1b445ed

I think I've explained it already a couple times why on support, but it's because after that transaction was sent a flux of new transactions have come in with higher priority, and backlogged it. I promise you'll get your money, and I even created a conflicting transaction for you with an *extremely* high fees:
https://live.blockcypher.com/btc/tx/c0c364ec8bfee5059f6cb4a3fe1578643ce5bce43b2f5510d25822364732ff59/

There's nothing else I can do, and you just need to be patient, and I promise you'll get your money.

Incidentally, once 0.12 bitcoin comes out, this will be supported much better and won't be a problem.

Turns out this was the cause: https://www.reddit.com/r/Bitcoin/comments/3ur5ma/stuck_transactions/cxh9o4x

looks like quite nasty, hopefully there will be some fixes soon :/

[ranlo]

This is just a heads up. I've been waiting for more then 2.5 hours for a withdraw to confirm. I'm posting the txid to see if anybody can see why its taking so long.

txid: e5a361b7da376bcf7f9575e1a16414faac6261f850740dabf9d9f6c0f1b445ed

I think I've explained it already a couple times why on support, but it's because after that transaction was sent a flux of new transactions have come in with higher priority, and backlogged it. I promise you'll get your money, and I even created a conflicting transaction for you with an *extremely* high fees:
https://live.blockcypher.com/btc/tx/c0c364ec8bfee5059f6cb4a3fe1578643ce5bce43b2f5510d25822364732ff59/

There's nothing else I can do, and you just need to be patient, and I promise you'll get your money.

Incidentally, once 0.12 bitcoin comes out, this will be supported much better and won't be a problem.

I just want to say... this is ridiculous (not you, the backlog). 0.002+ BTC fee on a somewhat small (byte-wise) transaction and after 7 hours it still has ZERO confirmations? Wow...

[RHavar]

I just want to say... this is ridiculous (not you, the backlog). 0.002+ BTC fee on a somewhat small (byte-wise) transaction and after 7 hours it still has ZERO confirmations? Wow...

Looks like it was caused by a DoS vulnerability in bitcoin (see the reddit link above) but fortunately it appears that miners are no longer mining (?) the exploiting transactions, so the backlog has cleared up and it should be business as usual.

(I hope the miners have figured out how to identify and remove the exploiting transactions, rather than just the attacker has stopped)

[oryeger]

This is just a heads up. I've been waiting for more then 2.5 hours for a withdraw to confirm. I'm posting the txid to see if anybody can see why its taking so long.

txid: e5a361b7da376bcf7f9575e1a16414faac6261f850740dabf9d9f6c0f1b445ed

I think I've explained it already a couple times why on support, but it's because after that transaction was sent a flux of new transactions have come in with higher priority, and backlogged it. I promise you'll get your money, and I even created a conflicting transaction for you with an *extremely* high fees:
https://live.blockcypher.com/btc/tx/c0c364ec8bfee5059f6cb4a3fe1578643ce5bce43b2f5510d25822364732ff59/

There's nothing else I can do, and you just need to be patient, and I promise you'll get your money.

Incidentally, once 0.12 bitcoin comes out, this will be supported much better and won't be a problem.

I just want to say... this is ridiculous (not you, the backlog). 0.002+ BTC fee on a somewhat small (byte-wise) transaction and after 7 hours it still has ZERO confirmations? Wow...

few weeks back I had to wait 14 hours for my transaction to show !

[FX_Trader]

I love playing this game, today won some bits, earlier lost, but the main thing is I love it !!

[oryeger]

Hi Ryan, I have been trying to figure out the engine behind that makes this game provably fair.
I have read the FAQ and the thread about  "Fair Seeding Event".

I understood that you have generated 10 million hashes (with a private key and the hash from an arbitrary block set in the future).
And I understand that you play the game backwards from the 10th million hash to the 1st.
The thing I fail to understand is how the bust odd is derived from the hash that is played at the moment.

here is a quote from dooglus:

Moneypot will play through that chain of hashes, in reverse order, and use the hashes to determine the crash point in a provably fair manner.

here is a quote from the FAQ:

Third, it works out what the multiplier would be if there was no house edge.

I know i`m missing a component/level to understand it and I hope you or anyone else can explain it to me in ELI5 form.

[blockage]

The thing I fail to understand is how the bust odd is derived from the hash that is played at the moment.

I know i`m missing a component/level to understand it and I hope you or anyone else can explain it to me in ELI5 form.

The exact algorithm was describe in the 'provably fair seeding event'. Here it is without additional noise:

The method to convert a game hash, mix it with the picked client seed to a money pot multiplier:

Code:

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));
}

Unfortunately, this isn't exactly ELI5. Here is also the original code that gives more details to the last line. You can also take a look at how the winning probability and the house edge are derived from the above function. The details are in the code of the onsite calculator. If you're really don't feel comfortable reading code, I can try again..

[michael555]

Does anybody have the script https://www.bustabit.com/user/crminer
uses?

[dooglus]

Code:

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));
}

Or, in English:

To get from the sha256 hash to the crashpoint:

1) if the hash is exactly divisible by 101, crashpoint is 0x
2) otherwise crashpoint is (1 + 99e/(e-h)) / 100 to 2 decimal places, where e is 2^52 and h is the first 13 characters of the hash

Intuitively:

h ranges from 0 to 2^52-1.

If h is very small, e-h is very big, 99e/(e-h) is very close to 99, and the crashpoint is 1.00x.

If h is very big, e-h is small, 99e/(e-h) is very big, and the crashpoint is huge.

[cancerbola]

Does anybody have the script https://www.bustabit.com/user/crminer
uses?

It's just a 1000x martingaling script (or as many people call it, a "nyan chaser").
But it's quite risky because sometimes a 1000x only comes after 10k rounds, so you end up "martinfailing" (go bankrupt)
However, the BaB gods have been relatively nice in November, so there weren't any severe "nyan droughts" recently.

I would suggest that you start chasing nyan only after it hasn't come for ~4k rounds or so.

[dooglus]

I would suggest that you start chasing nyan only after it hasn't come for ~4k rounds or so.

Waiting for a 4k nyan-gap won't improve your odds at all. You know that, right?

All it will do is mean that you are playing less games, and so your money will last longer just because of that fact.

[RHavar]

Hi Ryan, I have been trying to figure out the engine behind that makes this game provably fair.

Basically the provably fair needs to show two main things:

a) That I've predetermined the outcomes  (so I can't change them in response to players bets)
b) That they come from a fair distribution (so you get the house edge you expect) without being predictable (so players can't cheat)

probably the simplest provably fair scheme would be for me to pick a random phrase, and commit to it (by publishing a hash). Add in some information I don't control (e.g. a block hash) and then use it to seed a pseudo-random-number-generator (preferably a cryptographic one, like Just-Dice uses to prevent leaking internal state that would allow players to cheat me). I could play through a day/week/year worth of game outcomes, then publish the seed I used.  That would satisfy both a) and b)  but kind of sucks, because you have to wait till the end of  day/week/year to do any verification. Also it has a problem with switchovers.



So what we use instead is a really cool chain of sha256 hashes (in our case 10M of them), which has some really nice desirable properties:
a) It's basically random  (so it's good enough to use as a source for the game bust data itself)
b) It can't be reversed (so players can't cheat me)
c) Arbitrary preimages can't be generated (so I can't cheat players)

So basically I have:
1=  Seed
2= Hash of 1
3= Hash of 2
4= Hash of 3
5= Hash of 4
...
10M=  Hash of 9,999,999


So if you know what N is, you can compute all the way down to the last hash. But you can never compute to 1. If you know what N is, you can check that it really was predetermined if  N+1 was really the hash of N. Since players can compute "downwards" it means I need to play the games in reverse. This then allows you to generate all the previous hashes (verify all previous games) without seeing future games (prevent players cheating)


So with the hash chain established, the only important thing to do is create a function which maps a hash onto the correct distribution (and that's the function that Dooglus/Blockage explain a few posts above me.

[oryeger]

Code:

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));
}

Or, in English:

To get from the sha256 hash to the crashpoint:

1) if the hash is exactly divisible by 101, crashpoint is 0x
2) otherwise crashpoint is (1 + 99e/(e-h)) / 100 to 2 decimal places, where e is 2^52 and h is the first 13 characters of the hash

Intuitively:

h ranges from 0 to 2^52-1.

If h is very small, e-h is very big, 99e/(e-h) is very close to 99, and the crashpoint is 1.00x.

If h is very big, e-h is small, 99e/(e-h) is very big, and the crashpoint is huge.

1) How can I divide a hash string by a number or use in in a math forumla? doest hashes have numerical value ?
2) the value of e is generated randomly or its derived out of something ?

if you can show me an exmaple of this calculation it would be great.

2) Also how are the odds of X multiplier to appear are calculated ?


RHavar: thank you for the explanation that part I understood but you made it even clearer.
I dont really know about how dice works at the backend but there is a method used by jackpot sites in the cs:go community where they used a secret string + a random generated number into a hash. they publish the hash and the secret before the game ends, once the game concludes you can take the winning number and the secret string and hash to check if it matches the hash that was published.
I can understand that this method is weak because you need to trust the site owners to generate true random numbers and strings.

[dooglus]

1) How can I divide a hash string by a number or use in in a math forumla? doest hashes have numerical value ?

Good question. Hashes are really just very big numbers. They are usually written in hexadecimal (base 16) which uses digits 0-9 and a-f. 'a' means 10, 'b' means 11, ..., 'f' means 15.

Rather than the decimal (base 10) system, where "246" means 2 hundreds (ten squared), 4 tens and 6 ones, in hexadecimal "246" would mean 2 (16 squareds), 4 sixteens and 6 ones.

So even though the hash string has letters a through f in it, it is still just a number, and can be divided by other numbers.

2) the value of e is generated randomly or its derived out of something ?

e is just 2 to the power of 52. It is one greater than the maximum value that can be represented by a 13 digit hexadecimal number.

if you can show me an exmaple of this calculation it would be great.

I can try. I just went to bustabit and screenshotted the most recent crashes:



I copied the full hash of the top row. It is 0f81acc25a875c843f3ee3f9563bfa875be311d7585306e743120a4e68f51f0f

Then I checked that each of the next hashes forms a chain:

Code:

$ echo -n 0f81acc25a875c843f3ee3f9563bfa875be311d7585306e743120a4e68f51f0f | sha256sum
1da773ad50c9f5ce2098713e90bfe667c467fb1e1b14d3623113336899cfff4c  -

$ echo -n 1da773ad50c9f5ce2098713e90bfe667c467fb1e1b14d3623113336899cfff4c | sha256sum
c0799484b3dda03da0ab75f21ea6c34ee636dcfa40be81bc44ade2bcd6760754  -

$ echo -n c0799484b3dda03da0ab75f21ea6c34ee636dcfa40be81bc44ade2bcd6760754 | sha256sum
ba5faf9f3b9c84ac1d7ddc957a2376e9cb3638ac6f54ad4274febdf5beec2632  -

$ echo -n ba5faf9f3b9c84ac1d7ddc957a2376e9cb3638ac6f54ad4274febdf5beec2632 | sha256sum
5d3ebb05c6b2b5ab6a7397a820ae8d710712f7cf2376630dd2ed3fa747ec325c  -

That shows that the sha256 hashes are chained as described. Each game's hash is the sha256 hash of the next game's hash.

To do the calculations, I'm going to use 'nodejs', a standalone Javascript interpreter:

Code:

$ nodejs
> crypto = require('crypto');
> e = Math.pow(2,52); // e is just 2^52
4503599627370496
> clientSeed = '000000000000000007a9a31ff7f07463d91af6b5454241d5faf282e5e0fe1b3a'; // hash of block 339300
'000000000000000007a9a31ff7f07463d91af6b5454241d5faf282e5e0fe1b3a'

> serverSeed = '0f81acc25a875c843f3ee3f9563bfa875be311d7585306e743120a4e68f51f0f'; // this is the server seed shown when the game is over
'0f81acc25a875c843f3ee3f9563bfa875be311d7585306e743120a4e68f51f0f'
> hash = crypto.createHmac('sha256', serverSeed).update(clientSeed).digest('hex'); // combine the server seed with the client seed
'1cda7a31c271dd9e8b95798aedb9d6adfd83de975f5edd8315de7675b1cdc9ea'
> first13 = hash.slice(0,13); // take the first 13 digits of the hash
'1cda7a31c271d'
> h = parseInt(first13, 16); // convert it from hexadecimal to decimal
507594856474397
> Math.floor((100 * e - h) / (e - h)) / 100 // apply the formula to get the crash point
1.12

> serverSeed = '1da773ad50c9f5ce2098713e90bfe667c467fb1e1b14d3623113336899cfff4c';
'1da773ad50c9f5ce2098713e90bfe667c467fb1e1b14d3623113336899cfff4c'
> hash = crypto.createHmac('sha256', serverSeed).update(clientSeed).digest('hex');
'e2b986d935a2696722fe80a862ea044a12682341175fda4b6419524f2b38e75b'
> first13 = hash.slice(0,13);
'e2b986d935a26'
> h = parseInt(first13, 16);
3988583347345958
> Math.floor((100 * e - h) / (e - h)) / 100
8.66

> serverSeed = 'c0799484b3dda03da0ab75f21ea6c34ee636dcfa40be81bc44ade2bcd6760754';
'c0799484b3dda03da0ab75f21ea6c34ee636dcfa40be81bc44ade2bcd6760754'
> hash = crypto.createHmac('sha256', serverSeed).update(clientSeed).digest('hex');
'6798fcb15192969301ce58db9010a8d3ad4c53d834a63fd090d41851f5b07900'
> first13 = hash.slice(0,13);
'6798fcb151929'
> h = parseInt(first13, 16);
1822508354705705
> Math.floor((100 * e - h) / (e - h)) / 100
1.67

> serverSeed = 'ba5faf9f3b9c84ac1d7ddc957a2376e9cb3638ac6f54ad4274febdf5beec2632';
'ba5faf9f3b9c84ac1d7ddc957a2376e9cb3638ac6f54ad4274febdf5beec2632'
> hash = crypto.createHmac('sha256', serverSeed).update(clientSeed).digest('hex');
'bed205075a7b1ce33616840b9681a5b84522bf34b26ff3e758c3eb788b1e49af'
> first13 = hash.slice(0,13);
'bed205075a7b1'
> h = parseInt(first13, 16);
3356947788441521
> Math.floor((100 * e - h) / (e - h)) / 100
3.89

> serverSeed = '5d3ebb05c6b2b5ab6a7397a820ae8d710712f7cf2376630dd2ed3fa747ec325c';
'5d3ebb05c6b2b5ab6a7397a820ae8d710712f7cf2376630dd2ed3fa747ec325c'
> hash = crypto.createHmac('sha256', serverSeed).update(clientSeed).digest('hex');
'd7f97ec4c79f14c1e731101c7422facd5e0662eeb5481eaba9a7a681588f5697'
> first13 = hash.slice(0,13);
'd7f97ec4c79f1'
> h = parseInt(first13, 16);
3799465178462705
> Math.floor((100 * e - h) / (e - h)) / 100
6.34

I had to tell it the client seed, which is the hash of block 339300 - a block height that was picked before the block was solved, in the seeding event post, and each of the server seeds. From that information it was able to calculate the 5 crash points from the image. I didn't check whether the hashes were divisible by 101 (because I don't know how to using node), so let's do it in Python:

Code:

$ python
Python 2.7.9 (default, Mar  1 2015, 12:57:24) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0x0f81acc25a875c843f3ee3f9563bfa875be311d7585306e743120a4e68f51f0f % 101
20L
>>> 0x1da773ad50c9f5ce2098713e90bfe667c467fb1e1b14d3623113336899cfff4c % 101
43L
>>> 0xc0799484b3dda03da0ab75f21ea6c34ee636dcfa40be81bc44ade2bcd6760754 % 101
41L
>>> 0xba5faf9f3b9c84ac1d7ddc957a2376e9cb3638ac6f54ad4274febdf5beec2632 % 101
4L
>>> 0x5d3ebb05c6b2b5ab6a7397a820ae8d710712f7cf2376630dd2ed3fa747ec325c % 101
22L

That's showing the remainder after dividing each hash by 101. It's not zero for any of them, so the crash point is never 0x.

2) Also how are the odds of X multiplier to appear are calculated ?

I don't remember the details of that. I did work through it once, and found an error, so Eric (I think) ended up fixing the code.

I can understand that this method is weak because you need to trust the site owners to generate true random numbers and strings.

Yes - it's one thing for the owners to prove that they picked the outcome before you played (by publishing its hash), but that's not enough. They should also be able to prove that they had no control of the outcome. If you're playing roulette, and picking red or black, it's not enough for me to prove that I committed to rolling green "zero" before you made your bet. I should also be able to prove that I'm not picking zero more often than I should be.

That is the point of the "seeding event" I linked to above.

[RHavar]

Thanks Dooglus for writing that up, you do a great job at explaining things.

2) Also how are the odds of X multiplier to appear are calculated ?

The odds are derived from the function that converts a hash to a bust point. So if you're a programmer, by far the easiest way is to write a loop that generates a million random hashes and computes the bust of them. Count how many are >= X, and divide by a million. Assuming X is not too big, you'll have a very good estimate without needing to trust any maths.

In untested psuedo-code:

Code:

var count = 0;
for (var i = 0; i < 1e6, ++i) {
   var hash = sha265(i);
   if (crashPointFromHash(hash) >= 2)
      ++count;
}
console.log('The game gets to 2x ', count/1e4, '% of the time);

Which should output something like "The game gets to 2x 49.256% of the time"  (and if you add the bonuses, you'll see the house edge is a little under 0.5% in this case)
 

there is a method used by jackpot sites in the cs:go community where they used a secret string + a random generated number into a hash. they publish the hash and the secret before the game ends, once the game concludes you can take the winning number and the secret string and hash to check if it matches the hash that was published.
I can understand that this method is weak because you need to trust the site owners to generate true random numbers and strings.

Lots of times people suggest to me using things like this, where everyone has a client seed (or something like that) and they're all mixed together, and a result is formed.  But in general, that would allow me to easily cheat if I controlled one of the accounts (and no one would have any way of knowing if i did).

The bustabit provably fair system is actually quite elegant, and I haven't seen anything that I'd consider better or an improvement on it =)

[dooglus]

Code:

   var hash = sha265(i);

Pretty edgy of you to use sha256's unpopular twin brother sha265!

[RHavar]

For some people who were having trouble connecting, I've issued a new ssl certificate that should hopefully fix that. Also thanks to a patch by kungfuant, the game client is significantly faster.

And in other news, we set a record of having 173 people online at once! (Although the vast majority are idlers)

[Mist]

Code:

   var hash = sha265(i);

Pretty edgy of you to use sha256's unpopular twin brother sha265!

We got a badass over here