Bcgame seed-pair games allow separate checks of commitments and results

Server-seed commitments and result replay answer different questions

The commitment comparison checks the revealed seed's hash against the earlier hash, while result replay checks the calculation for the selected round.

The server-seed commitment

The operator conceals the active server seed and initially publishes its hash. A hash is a cryptographic fingerprint derived from an input. The published Classic Dice checker calculates the server-seed commitment using SHA-256. A copy saved before the seed enters use provides the reference for assessing its later reveal. The player can contribute a client seed after receiving that commitment where the game's seed settings support it.

The displayed game result

A result checker combines the revealed seed with the other inputs according to the selected game's algorithm. It converts the cryptographic output into a game outcome, which you compare with the result recorded for that round. A matching fingerprint establishes only the commitment comparison. Reproducing the roll or other result also requires the correct conversion method and any game settings affecting that outcome.

The completed round's inputs determine the calculation

A seed-pair check needs the values associated with the completed bet, including its recorded nonce and original client seed. The published Classic Dice verification tutorial identifies a past wager by its game ID and opens its Verify view. Those details connect the calculation to a particular round; current seed settings can describe a different pair.

These are variable round inputs, not fixed values shared by every account. The game implementation determines how the checker combines them. Other game types can require different records, so this seed-pair table doesn't establish compatibility with every casino result.

What does a matching server-seed hash prove?

A matching hash shows that the revealed seed reproduces the recorded commitment, assuming the checker uses the correct encoding. It doesn't reveal the hidden input behind an active commitment. SHA-256 has no practical reversal method for recovering a suitably random secret seed. A completed round remains dependent on its client seed, nonce, and game algorithm. Agreement on the server-seed fingerprint alone therefore leaves the actual game result unchecked.

View full-size image

Seed changes affect future rounds

Changing a client seed affects future bets; a completed round retains the seed inputs originally associated with it.

Revealing a retired server seed

The platform keeps an active server seed concealed to prevent players from calculating upcoming results from it. Seed rotation retires that seed and reveals it for retrospective checks. The published verification approach relies on this reveal; the commitment hash can't substitute for the original server seed in the result calculation.

Placing another wager isn't a prerequisite for checking a completed round whose original inputs are available.

Preserving the earlier round's inputs

Current seed settings describe the current pair. An earlier bet belongs to the pair active when the platform accepted it. A later client-seed change doesn't rewrite that bet's recorded inputs. Using the replacement seed in a retrospective calculation checks a different input combination.

Verification uses game data. An external wallet's recovery phrase has no role in this seed-pair calculation. Keep wallet recovery phrases and private keys out of fairness-checker fields. Reproducing a casino result doesn't require authorizing a transfer or exposing the credentials controlling cryptocurrency funds.

A missing earlier commitment limits the conclusion

Without a commitment recorded before seed use, a later hash match can't independently establish when the platform committed to that seed.

An earlier saved copy or independently timestamped record may supply that reference. A seed and a hash supplied together can demonstrate agreement between those values without establishing their earlier publication.

You can still reproduce a result when the original inputs and applicable algorithm are available. That tests the calculation for the supplied data. It doesn't restore the missing record of the original commitment, and a missing record alone doesn't prove manipulation.

A discrepancy should identify the game, relevant implementation, exact inputs, and differing outputs. A mismatched hash can also reflect incorrect text or encoding. Preserve the distinction between a calculation disagreement and a missing historical reference before drawing a conclusion about either.

Game versions and text encoding determine checker compatibility

Classic Dice and wheel use specific calculations

Reproducing a round requires the game's specific conversion from cryptographic output to displayed result. Published Classic Dice seed-pair checkers use HMAC-SHA256, a keyed hashing construction. The server seed provides the key; the message joins the client seed and nonce with a colon. The July 15, 2020 Classic Dice walkthrough instead describes plain SHA-256 over a colon-separated seed combination. A game name alone doesn't establish which implementation applies to a historical round. Wheel's published method uses HMAC-SHA256 and maps its output into a wheel position. Its risk level, segment count, and applicable payout schedule determine the multiplier for that position.

Client seeds remain character strings

The published Classic Dice checkers pass the client seed into the HMAC message as text. Characters that also represent hexadecimal digits don't automatically turn that text into encoded bytes. Preserve the exact characters and capitalization the implementation uses; don't manually convert the client seed into a hexadecimal byte sequence. Parsing parts of the resulting hash as hexadecimal is a separate operation. The distinction concerns what enters the hashing function and how the checker interprets its output.

Different nonces can produce the same displayed result

The nonce distinguishes round inputs within a seed pair, but it doesn't make every displayed roll unique. Dice games map many possible cryptographic outputs into fewer displayed values, so different nonces can produce the same final number. That repetition doesn't, by itself, establish reuse of the same inputs. A repeated displayed result also differs from a collision in the complete cryptographic hash. The recorded counter remains necessary for reproducing the particular bet.

The check's scope ends at the selected game calculation

A successful result check doesn't remove the house edge or make a completed wager reversible. The game's probabilities and payout rules determine its expected return. A correct calculation can still produce a losing round. Seed data also doesn't establish who controls deposited cryptocurrency.

A casino checker doesn't validate a sportsbook settlement. That question concerns the accepted selection, event result, and applicable market rules. A reproduced dice roll supplies no evidence about those facts. Likewise, a cryptographic check of casino inputs doesn't establish whether a withdrawal will complete.

If the dispute concerns a casino outcome, choose a checker implementing the exact game and relevant version. For a sports settlement, retain the accepted wager and its applicable rules alongside the event result before deciding whether the settlement follows those terms.