Unbiased Coin Toss

A coin toss is the simplest possible random event: two outcomes with equal probability.

In practice, many digital coin toss implementations are not actually 50/50.

This document explains:

• Why binary randomness is frequently biased
• How common implementations fail
• How to generate a provably fair and auditable coin toss
• How to derive it from deterministic cryptographic entropy

The Assumption: “It’s Just 0 or 1”

Developers often assume:

If the RNG is good, then:

random % 2

must produce a fair result.

This assumption is not always correct.

Even when the bias is small, it becomes meaningful in:

• Gambling systems
• Competitive games
• Reward mechanics
• Adversarial environments

A tiny bias repeated millions of times becomes measurable.

Where Bias Appears

Bias enters when the underlying random source:

• Is not uniformly distributed
• Has a range that is not divisible by 2
• Is truncated incorrectly
• Uses floating-point rounding

Examples of problematic sources:

• Poor PRNGs
• Time-based seeds
• Low-entropy hashes
• Integer overflow behavior

The Modulo Problem (Even With “Good” Random)

If the entropy space is not an exact multiple of 2, then:

• Some outputs appear slightly more often.

Example:

If values range from 0–9 (10 values)

10 mod 2 = 0 → safe

But if values range from 0–255 (256 values)

256 mod 2 = 0 → still safe

Now consider truncated entropy:

0–254 (255 values)

255 mod 2 = 1

Now one side appears slightly more often.

This happens frequently when:

• Developers slice bytes incorrectly
• Use signed integers
• Use partial hash output

Cryptographic Coin Toss Design

A correct coin toss should:

• Use high-entropy input
• Be deterministic from a seed
• Avoid modulo bias
• Be replayable
• Be independently verifiable

Deterministic Derivation Pattern

Given a final randomness seed: seed

We derive entropy using: hash(seed : counter)

The counter ensures:

• Independent outcomes
• No entropy reuse
• Order-independent verification

Converting Entropy Into a Coin Toss

Correct method:

1. Take 64 bits of entropy
2. Use rejection sampling if needed
3. Map to two outcomes

Simplified approach:

value = entropy % 2

But only if the entropy range is a power of two.

Safer approach:

1. Use full 64-bit space
2. Reject values outside the largest multiple of 2

This guarantees:

• Exactly 50% probability.

Mapping Outcomes

Common mappings:

• 0 → Heads
• 1 → Tails

or

• false → Fail
• true → Success

The important part is:

• The mapping must be documented and immutable.
• Changing mappings later breaks audits.

Why Deterministic Coin Toss Matters

In adversarial systems:

• Players may suspect manipulation
• Operators may be accused of bias
• Regulators may require audit trails

A deterministic coin toss provides:

• Replayability
• Public verification
• Zero hidden state

Anyone with the seed can recompute the result.

Real-World Failure Modes

Observed issues in production systems:

• Server-Only RNG
  • Players cannot verify fairness.
• Time-Seeded Random
  • Predictable by attackers.
• Client-Side Random
  • Can be modified or replayed.
• Floating-Point Based Coin Toss
  • Rounding errors skew probability.

Verifiable Coin Toss Requirements

A coin toss suitable for trust-sensitive environments must provide:

• Public inputs
• Deterministic math
• Stable specification
• Versioned derivation rules
• Independent recomputation

Without these, the result is:

• Trust-based, not provable.

Why This Matters More Than It Seems

A coin toss is often used as the root decision for:

• Turn order
• First player advantage
• Loot eligibility
• Matchmaking decisions
• Bonus triggers

If the root decision is biased:

• Everything built on top inherits that bias.

Key Takeaway

A fair digital coin toss (as generated by BlockRand) is not about generating 0 or 1.

It is about:

• Using unbiased entropy
• Deriving outcomes deterministically
• Preventing hidden influence
• Making the result independently verifiable

In adversarial or financial systems, a coin toss must be treated as a cryptographic protocol, not a UI animation.