Why Blinko Runs Two Fairness Schemes
What each scheme guarantees, why one is not enough, and how to tell which round you are holding.
One player or two
A fairness scheme has to stop whoever could rig the outcome from doing so. Who that is depends on how many people are in the round, and that is why there are two schemes rather than one.
In a solo or LIVE round there is one player and the operator. The only party who could manipulate the result is the operator, so the scheme has to bind the operator to a value it published in advance.
In a PvP duel there are three parties with an interest: the operator and two players. Binding the operator alone is not enough, because an outcome derived from one player's input could be steered by that player. The scheme has to make every party a contributor and none of them a controller.
The hash chain, for solo and LIVE
The operator generates a long sequence of seeds in advance, where each entry is the hash of the next. Publishing the first entry commits to the entire sequence, because producing any different continuation would require finding a hash collision.
Rounds consume the chain in order. The commit for a round is the previously revealed entry; after the round, the seed behind it is disclosed, and hashing that seed reproduces the commit. The chain moves one step forward.
The property this gives you is strong and simple: the operator fixed every future outcome before any of them was played, and each round proves its own link. Your client seed and a nonce go into the derivation, so you also contribute — but the chain is what makes the commitment credible over time rather than round by round.
Commit-reveal with two contributors, for duels
A duel commits to a server seed before the round, then requires both players to submit independent random values. The outcome is derived from all three together. If either player's contribution is missing, the round is cancelled rather than resolved, because an outcome derived from partial input is one that the remaining party could influence.
The derivation, set out in full on the fairness page, binds more than the seeds. A canonical byte string joins the match identifier, the round identifier, a generation counter and a round nonce alongside both client seeds, so that no two rounds can be made to share a derivation and no pair of identifiers can be rearranged into the same one.
The blast point and the first holder are then derived under separate HMAC domain tags from the same entropy. Using one derivation for both would let knowledge of either value say something about the other; separate domains make them independent.
The difference that trips people up
Both schemes commit with SHA-256, and they hash different things.
The chain hashes the seed as text — the 64-character hexadecimal string, encoded as UTF-8. The duel scheme hashes the raw 32 bytes that string represents. These produce entirely different digests from what looks like the same value.
If you check a LIVE round using the duel construction, the commitment will not match and you will conclude that an honest round was rigged. This is the single most likely way for a hand-check to go wrong, and it is why the verifier asks which kind of round you are holding before it computes anything.
Telling them apart
A chain round has a chain identifier, a chain index, one client seed and a nonce. A duel has a match identifier, a round identifier, two client seeds, a generation counter and a round nonce.
The blast-point formula is identical in both, and its distribution is the same game. Only the binding differs — what goes into the hash, and in what form. Everything downstream of that, including the distribution of outcomes, is the same game.