Bc.game provably fair result verification

The earlier hash anchors the revealed seed

The server-seed hash displayed before a bet provides the comparison point for the seed revealed later, creating a cryptographic commitment to the earlier value. The casino supplies the server seed and initially reveals its hash. A hash is a reproducible fingerprint of its input. It is designed to make finding another input with the same fingerprint computationally infeasible. The SHA-256 hash of the revealed server seed must match the server-seed hash recorded before the bet. This comparison checks whether the disclosure agrees with the earlier commitment.

Hash the revealed seed itself. Hashing the already-hashed commitment produces another digest and tests a different input.

A hash obtained only after the result cannot, by itself, establish what the operator displayed beforehand. Keep the original commitment with the relevant bet details. The replacement seed pair belongs to later bets, so its hash does not provide the comparison for a round played under the earlier pair.

A seed-pair check remains incomplete until its required server seed is available.

Client seeds and nonces identify the recorded bet

The client seed supplies the player-side input, while the nonce identifies the bet’s position within the seed pair’s sequence. The counter advances as bets occur in that sequence. This gives successive calculations different inputs even when the seeds stay unchanged. Different inputs do not mean that a game can never repeat an outcome. A dice roll can recur without the full cryptographic digest repeating. Copying the recorded nonce avoids confusing a previous bet with whichever counter value the account displays later.

Historical verification also needs the client seed associated with that bet. Changing the current client seed does not rewrite earlier inputs. The old server seed, old client seed, and recorded nonce must belong together. A seed change provides a disclosure boundary for supported seed-pair games; it does not supply the same verification method for every game.

Game calculations give the digest its meaning

HMAC is a hash-based message authentication code: a keyed calculation that combines a message with a separate key. In the published HMAC-SHA256 implementations for Classic Dice and Mines, the server seed supplies the key. Their message contains the client seed, a colon, and the nonce, in that order. The seed commitment and this keyed digest have different jobs. The commitment identifies the server seed, while the keyed digest provides data that the game converts into its result. Reproducing that conversion requires the applicable extraction, scaling, and rounding rules.

The Mines verifier produces an ordered list of board positions from its digest. Interpreting that list requires the mine count and the game’s position convention. The displayed layout must use the same position convention as the verifier’s list. Plinko’s published verifier uses HMAC-SHA512 and converts its generated bytes into left-or-right directions. Those directions describe the path calculation. The payout interpretation also needs the settings and payout rules associated with the game.

An intermediate hash match leaves the conversion unchecked. Compare the final game output in the units or positions that the recorded result uses.

A matching hash and a matching round

Consider a hypothetical completed seed-pair round; its seeds, nonce, recorded outcome, and comparison results are illustrative. A reader wants to know whether matching the server-seed hash also confirms the displayed outcome. Hashing the revealed seed produces exactly the commitment saved before the bet. That answers the question about the disclosed seed, without using the client seed or nonce.

View full-size image

The applicable result calculation then combines the revealed server seed with the client seed and nonce attached to the recorded round. It reproduces the recorded outcome. Both comparisons agree: the seed matches the earlier commitment, and the game calculation matches the recorded result. The conclusion applies to this round and this calculation.

Changing only the nonce would leave the server-seed hash unchanged while asking the verifier about a different point in the sequence. That calculation would no longer test the original bet, even though the commitment comparison could still match.

The game version determines the required verifier

Classic Dice has published verifier variants that turn the digest into a roll through different extraction methods. One uses leading bytes; another selects a window within the digest. A recorded round needs the method that governed that round, including its scaling and rounding behavior. The game name alone does not identify the applicable conversion. A mismatch caused by choosing the wrong variant cannot establish that the original outcome changed.

Crash uses a different arrangement: a sequence of round hashes linked through repeated hashing. The published hash-chain verifier derives earlier hashes from a supplied hash and calculates their multipliers. For salted Crash rounds, the verifier combines the round hash with the applicable salt to calculate its multiplier. It also supports an earlier unsalted mode. Salt configurations differ across parts of the game’s history. Personal client seeds and bet counters cannot replace those round-specific inputs.

Using the wrong salt can leave the supplied round hash intact while producing a different multiplier.

A mismatch therefore needs diagnosis at the level of the affected input or calculation. Transcription errors, an unrelated seed pair, or a verifier variant can change the comparison. Preserve the original values before correcting a copied input. The exact text encoding and message format also matter when implementing a calculation independently. Hexadecimal characters can represent text or encoded bytes; the applicable algorithm determines which interpretation the calculation requires. If the correct inputs and applicable algorithm still disagree, the round remains an unresolved verification problem.

A reproduced outcome leaves payout questions separate

Reproducing the recorded outcome establishes consistency with the disclosed inputs and applicable game calculation; it does not establish a credited balance, withdrawal eligibility, or the account’s access conditions. A verifier can reproduce a game result while the payout still follows that game’s betting rules. Bonus wagering requirements and crypto withdrawal conditions concern the funds in the account. They do not change the meaning of a matching seed commitment. Keep a disagreement about the generated outcome separate from a disagreement about the amount credited.

The house edge also remains part of the applicable game mathematics or payout rules. A reproducible result can still belong to a game with an expected advantage for the operator. Verification does not turn past results into a method for predicting a hidden future seed. A successful check provides a precise answer about a recorded round. An unexplained disagreement calls for that round’s preserved inputs, observed outcome, and applicable calculation.