Topic: bustabit – The original crash game - page 105. (Read 61394 times)

Your proposed system would allow you to batch verify that N games were predetermined. However it besides the usability problems (you need to collect the result hash, then collect all N games hashes before you can verify) it also suffers a critical flaw:  it doesn't prove the hashes are drawn from a fair distribution. If your scheme was used, Daniel could just pick all bad hashes and then commit to them.

As scant says, the hash chain method is far more elegant and offers all the guarantees yours does, plus more.

Justice is already proven. Every game commits to the next game in a huge chain. The current proof is simpler and more elegant than your proposed method.

I suggest you to educate yourself before making false claims, accuses and tell other people to perform actions to refute your baseless theories.

Daniel already has!

The current game is: 664966, which has a hash of `74543360092eac88c1ff6fcaf74328cce1e93900fbfef9204b5458365eeb2b1a`. What this means is game 664967 when hashed will be `74543360092eac88c1ff6fcaf74328cce1e93900fbfef9204b5458365eeb2b1a`. And you can verify this as soon as game 664967 ends.

But more than this, when game 664967 ends it gives you not only enough information to verify it (check it hashes to 74543360092eac88c1ff6fcaf74328cce1e93900fbfef9204b5458365eeb2b1a) but it also commits to the next game. This is why it's known as a hash chain, and can be repeated until the very end.


So more generally, all games commit to all future games -- and allow you to verify that.


And the next piece of the puzzle is a function that can convert a hash into a game result in a fair way (i.e. having the advertised house edge) and importantly has no concept of a "good" and "bad" hash before the hash chain was created (to avoid daniel creating a biased hash chain), hence the use of the blockchain for a client seed.

It looks like the site will temporarily stop taking commission:

You posted the link yourself... if a game was altered the whole chain would be broke and that verifier would show it

Ive played bustabit since 2015... Please learn about how the game works before you try to claim it was tampered. The games are hashed and chained together to prove the games havent been altered. If 1 game was changed or altered the entire chain would be broke and we would be able to tell.

the games are predetermined. Nothing has changed besides the part of the chain we're on

Over the past few days KLITZ has won 300 BTC, making him the new record holder on bustabit for highest net profit. Congratulations!

Ah, great, it really works. I just see (e.g. in Martingale script) function roundBit(bet), but editing of this function is full enough, it seems. Thanks!


Yeah, it was that issue. I just deleted the script and used the "Restore sample" button and everything works like a charm now.


Ok, thanks for the explanation, I'll try this, it looks like an useful function.


Thanks a lot for your explanation and also for all your work with bustabit, devans!

bustabit only allows betting of whole bits, so you can only bet multiples of 100 satoshis. Previously a bug in the script editor allowed invalid bets to be accepted and silently rounded. This bug has been fixed and script authors need to ensure that their bet sizes are valid.

Luckily the fix is very simple. You can use Math.round to round your wagers, so for example


would become


If you always want to round downwards or upwards, use Math.floor or Math.ceil respectively instead.


In case that's what you're using, the Martingale sample script also relied on the bug I mentioned, but has been fixed. To load the fixed Martingale script, delete it from the list of scripts, then click the orange "Restore samples" button.

Otherwise it's hard to say what the issue is without seeing the specific script. Most likely it is trying to place an invalid wager and failing.


The simulation mode lets you test a script without actually placing bets. If you enable simulation mode you will be able to choose your starting balance for the simulation. Running your script will then cause your simulated balance to increase or decrease, allowing you to see how a script would do on bustabit without risking any bits.

I'm back in game after 14 days, and I see there were some changes made on  bustabit page :

1/ Why is not possible anymore to set up "non integer" bet, let's say 3.5 bits ? It was possible before. Of course real bet was 3 bits, but if one has multiplier (in case of loss), let's say 2.5x, next bet has been calculated as 3.5 * 2.5, not 3 * 2.5 ... which was fine. Actually, it was only one great upgrade (in my eyes), comparing to bustabit v1. Anyway, why's not possible to set up bet in satoshis instead of bits, so, in my example above, 350 sats instead of 3.5 (bits) ?

2/ When I play auto-mode, in case of loss the script has been terminated, even if I have set up multiplier (in case of win and "return to the base bet", everything goes on without interruption).

3/ What is the "Simulation mode" checkbox beside the "Run script" green button ?


Thanks for the answers to my questions.

The expected median should indeed be 1.98x, but the actual median is going to vary significantly over a finite amount of games.  


That system is known as "provably fair" and contains absolutely everything you need to prove the game is fair. While i do admit it requires quite a bit of technical knowledge, it has the advantage that anyone can verify the game for everyone. So if you can find someone who understands how the maths primitives work, it should be easy to verify =)


If I was in his position, I would not do it either. If that knowledge affects your actions, I would say it's pretty unethical (as it'll either advantage/disadvantage  investors/gamblers). If that knowledge doesn't affect your actions, it's kind of pointless to know. I would definitely not want to put myself in a position where I could get influenced by it.


BTW, Daniel actually makes more money when the games are good than when the games are bad. His profit is a function of the amount wagered, and players are able to turn over a lot more when they're not getting raped.


The house edge can be 1%, but players lose 2%  .... but that doesn't mean there was cheating, it means there was variance. The provably fair system proves that the game outcomes have been decided from a probability distribution function that results in a 1% house edge. It's totally normal and expected that the games will be "good" and "bad" over a finite period of time

I'd encourage you to do the maths, or get someone to do it for you. Variance is far more of a bitch than almost everyone realizes. In the end, bustabit has done all that is possible to allow you to verify the games and the maths and check things -- the ball is really in your court on this one.

I watched a little. very few winners.

I assume he's thanking for admitting that MoneyPot was a disaster.

my posting was  regarding the moneypot disaster

What do you mean? Ryan probably doesn't want bustabit ( a long time project of his ) to be run by scammers, so he just offered around to people he trusted hence him saying ( to avoid a repeat of the moneypot disaster )

thx for admitting

good luck

I said that the players are better off without the bonus system than with it and that that statement is not in contradiction with the RTP being lower than before. The bonus system has nothing to do with the RTP. Of course a higher house edge is worse for players as a whole. But as I said, moving to a flat house edge was going to happen regardless of my decision to keep or remove the bonus system.

That being said, it is absolutely possible for most players–what Ryan called the "gambling players"–to be better off despite the RTP being lower when a large part of the wager volume was going to a small number of bonus-aware players. In other words, the return to bonus-unaware players may actually be higher than it was despite the higher house edge. However, I haven't run the numbers to confirm that and that's not the argument I'm making here.

You can't have a lower RTP AND be better off for the player.

Lower RTP = worse for the player.
Higher RTP = better for the player.