How BC.Game crash is verified: hash chain, salt and formula

BC.Game crash is one of the few games where every round is fixed before anyone places a bet, and BC.Game publishes enough for you to check that. This guide walks through what BC.Game's own documentation says: the hash chain, the salt, the formula that turns a hash into a multiplier, and how to check rounds yourself with our hash chain check and BC.Game's own verifier.

What BC.Game publishes about crash

BC.Game explains crash fairness in its help centre, in the article "Crash: ensuring fair play" and on its provably fair page. It also links a verification script hosted on GitHub under the bc-game-project account, and announced a change to the crash algorithm in a 2020 post on Bitcointalk. Everything below comes from those pages. Where they differ or leave a gap, we say so.

The hash chain

According to BC.Game's help centre, it generated a total of 10 million hashes before the game began. Each hash is the SHA-256 of the one created before it, so together they form a chain.

The chain is used in reverse order:

1. BC.Game creates the chain from a secret starting value by hashing it again and again with SHA-256.
2. The last hash created is used for the first round, the one before it for the second round, and so on.
3. When a round ends, its hash is shown in the game history.
4. Hashing that round's hash once gives the hash of the round before it.

Because SHA-256 only works in one direction, nobody can work out the next round's hash from the current one. But anyone can go backwards and confirm that each round's hash leads to the previous round's hash. If every link holds, the rounds came from a chain that existed before the bets were placed, and BC.Game could not have swapped a result after seeing the bets.

The salt

A hash chain alone has one weakness: the casino generates it, so in theory it could make many chains and keep a favourable one. A salt closes that gap by mixing in a value nobody knew when the chain was made.

BC.Game's GitHub verification page says it updated crash to use a salted hash at players' request, from bet number 2,561,902, and points to its Bitcointalk announcement from June 2020. In that post, BC.Game says each game hash is combined with HMAC-SHA256 with a salt: the hash of a pre-selected Bitcoin block, number 635,380, which had not yet been mined when the announcement was made. The verifier on GitHub has a separate salt field for this reason.

The help centre article does not mention the salt. Its worked example applies the formula straight to the round hash. We could not confirm from BC.Game's current help pages whether the salt has changed since 2020, so use the salt shown in BC.Game's own verifier or fairness panel when you check a multiplier.

From hash to multiplier

BC.Game's help centre gives the conversion step by step:

1. Take the first 13 hexadecimal characters of the hash. That is 52 bits.
2. Divide that number by 2^52 to get a number X between 0 and 1.
3. Calculate 99 divided by (1 minus X). The 99 instead of 100 is the 1% house edge.
4. If the result is below 100, set it to 100.
5. Round down and divide by 100. That is the crash multiplier.

Under the salted version announced on Bitcointalk, the 13 characters are taken from the HMAC-SHA256 of the round hash with the salt, not from the round hash itself. The arithmetic after that is the same.

The help centre works one example: a hash starting 6b5124897c3c4 gives X of about 0.4192, then 99 divided by 0.5808 is about 170.46, which rounds down to 170 and becomes a 1.70x crash.

What the formula means for your odds

Because X is spread evenly between 0 and 1, the formula gives clean odds:

• Instant crash at 1.00x. This happens when X is below 0.01, so about 1% of rounds.
• Reaching any multiplier M. The chance a round gets to M or higher is about 99% divided by M.

Whatever target you set, the expected return is about 99% of what you bet. No auto cash out setting changes that. Past rounds do not help either: each hash is effectively random, so a run of low crashes says nothing about the next one. Our crash predictor guide explains why apps that claim to predict the next round cannot work.

Check rounds with our hash chain check

This confirms that rounds came from one pre-committed chain:

1. In BC.Game crash, open the round history and copy the hashes of two or more consecutive rounds.
2. Open our hash chain check.
3. Paste the hashes one per line, in the same order as the history. Newest first or oldest first both work, as long as no round is skipped.
4. Run the check. Hashing a later round's hash once should give the hash of the round before it.

If every link matches, those rounds were fixed before play. If a link breaks, first make sure you copied the rounds in order with none missing. A real break in consecutive rounds would be a serious finding.

Check the multiplier with BC.Game's verifier

Our chain check proves the rounds are linked. To confirm the multiplier of a given round, use BC.Game's own verification script:

1. Paste the round's game hash.
2. Enter the salt.
3. Set the amount of games you want calculated from that hash.
4. Compare each bust value with the multipliers in BC.Game's round history.

If the bust values match the history and the chain links hold, the round was both fixed in advance and scored with the published formula.

What this does and does not prove

• It proves the result was fixed before bets. Neither BC.Game nor any player could change a round after it started.
• It does not remove the house edge. About 1% of everything wagered goes to the house over time.
• It covers crash only. BC.Game's other originals, such as dice, use a server seed, client seed and nonce instead; check those in our verifier with BC.Game selected.
• It says nothing about payouts. See our BC.Game audit for licence details and our withdrawal test.

Sources

• BC.Game help centre: Crash, ensuring fair play
• BC.Game help centre: Game fairness
• BC.Game: Provably fair
• BC.Game crash verification script (bc-game-project on GitHub)
• BC.Game on Bitcointalk: Crash game reseeding event (June 2020)