◈ Master Index Specs LATTICE CSDM The Book University Chronicle Crew Architecture Context Logs TODOX Products

Entropx Provably Fair

SPEC_ENTROPX_PROVABLY_FAIR.md · 2026-06-15

name: SPEC_ENTROPX_PROVABLY_FAIR

description: ENTROPX Provably Fair Commit-Reveal Protocol — SPECIFIED ✓; SHA-256 commitment + HMAC-SHA256 round derivation + offline verification; dual proof (quality+fairness); potential Claim 11; κ 2026-06-15

metadata:

type: project

SPEC — ENTROPX Provably Fair Protocol

Status: SPECIFIED ✓

Author: κ (C.L.O.D.) ⊢ α

Date: 2026-06-15

Authored under: ⊢.α ENTROPX build chain

PURPOSE

Casino regulators and players need TWO proofs from any RNG system:

Quality proof — the numbers are genuinely random (NIST SP 800-22 audit)
Fairness proof — the house cannot choose outcomes after seeing bets (commit-reveal)

ENTROPX already provides proof #1. This spec adds proof #2 via a commit-reveal scheme — the cryptographic standard used in blockchain gaming, licensed casino RNGs (iTech Labs, eCOGRA), and regulatory submissions worldwide.

The result: ENTROPX becomes the only entropy system that simultaneously proves both quality (NIST) and honesty (commit-reveal) in one auditable package. No other licensed casino RNG makes both proofs in real time, in a browser, with open verification.

The Chronogeome game demo becomes the live regulator-facing demonstration of both proofs.

CORE CONCEPT — HOW IT WORKS BACKWARDS

Standard forward flow:

entropy → outcome → player bet → payout

Provably fair backwards verification:

revealed seed → HMAC → outcome → player checks it matches

The player cannot know the outcome before betting (because the seed is committed but hidden).

The casino cannot change the outcome after betting (because the commitment is locked before any bet).

Anyone can verify both facts, offline, with standard tools.

PROTOCOL FLOW


SERVER                                   PLAYER
  │                                          │
  ├─ 1. generate server_seed (ENTROPX)       │
  │      [8-source, NIST-verified, 256-bit]  │
  │                                          │
  ├─ 2. commitment = SHA-256(server_seed)    │
  ├──── 3. publish commitment ──────────────►│
  │                                          │
  │                                          ├─ 4. generate or choose client_seed
  │◄─── 5. submit client_seed ───────────────┤
  │                                          │
  ├─ 6. nonce++                              │
  ├─ 7. outcome = HMAC-SHA256(server_seed,   │
  │      "entropx:v1:" + client_seed +       │
  │      ":" + str(nonce))                   │
  ├──── 8. publish outcome ─────────────────►│
  │                                          │
  │    [game/bet plays out on outcome]        │
  │                                          │
  ├─ (after N rounds OR on player request)   │
  ├──── 9. reveal server_seed ──────────────►│
  │                                          │
  │                                          ├─ 10. verify SHA-256(server_seed) == commitment ✓
  │                                          ├─ 11. verify HMAC(server_seed, client_seed:nonce) == outcome ✓
  │                                          │      (both verifiable offline with any SHA-256/HMAC tool)
  │                                          │
  ├─ 12. generate new server_seed            │
  ├─ 13. publish new commitment ────────────►│
  │    [next session begins]                 │

COMPONENTS

C1 — Server Seed

Generated by ENTROPX 8-source engine (Sinai billiard + Whirlwind + Cycling detectors + Magnetic gauntlet + Dwell sequence + Stopping time + Spinning surfaces + Target miss)
Length: 256 bits (32 bytes)
Quality: NIST SP 800-22 Rev 1a verified at generation time
Secret until reveal (step 9)
Never reused across sessions

C2 — Commitment Hash

commitment = SHA-256(server_seed)
Published to player BEFORE any game action begins (step 3)
Immutable — server cannot change server_seed without invalidating the commitment
Displayed in game HUD and on player's session receipt

C3 — Client Seed

Player-supplied 128-bit (16-byte) hex string
Default: generated in browser via window.crypto.getRandomValues() — player can replace with any string they choose
Purpose: player agency. Even if the casino wanted to manipulate the outcome, they committed before knowing the client seed — they cannot retroactively choose an outcome that was favorable
Submitted to server AFTER commitment is received (step 5)

C4 — Nonce

Monotonically increasing integer per server_seed session
Starts at 1, increments each round
Scope: per server_seed — resets to 1 on new session (new server_seed)
Prevents replay: two identical (server_seed, client_seed) pairs produce different outcomes across rounds

C5 — Round Outcome Derivation


outcome_bytes = HMAC-SHA256(
    key   = server_seed,
    data  = "entropx:v1:" + client_seed + ":" + str(nonce)
)

Returns 32 bytes of outcome entropy
outcome_bytes[0..3] → normalized float [0,1) for game result

value = int.from_bytes(outcome_bytes[0:4], 'big') / 0xFFFFFFFF

Additional bytes available for secondary outcomes (card draws, reel positions, etc.)
Published to player immediately after derivation (step 8)

C6 — Verification Function (Client-Side)

Any player can verify offline:


import hmac, hashlib

def verify_round(server_seed_hex, client_seed, nonce, commitment_hex, outcome_hex):
    server_seed = bytes.fromhex(server_seed_hex)
    
    # Check commitment
    computed_commitment = hashlib.sha256(server_seed).hexdigest()
    assert computed_commitment == commitment_hex, "COMMITMENT MISMATCH — server changed seed"
    
    # Recompute outcome
    data = f"entropx:v1:{client_seed}:{nonce}".encode()
    computed_outcome = hmac.new(server_seed, data, hashlib.sha256).hexdigest()
    assert computed_outcome == outcome_hex, "OUTCOME MISMATCH — result was altered"
    
    return True  # Game was provably fair

This runs in browser, Python, Node, any environment with SHA-256 and HMAC.

C7 — Session Rotation

Default rotation: every 100 rounds OR on player request
Rotation sequence: reveal current server_seed → NIST audit result for that seed → commit new server_seed
Rotation prevents long-run statistical analysis with known seed material
All revealed seeds logged to player's session audit trail

C8 — API Endpoints (oracle_toll.py extension)


POST /pf/session/new
    Response: { session_id, commitment, nist_p_monobit, nist_p_runs }

POST /pf/round
    Body: { session_id, client_seed }
    Response: { nonce, outcome_hex, outcome_float }

POST /pf/reveal
    Body: { session_id }
    Response: { server_seed_hex, rounds_completed, new_commitment }

GET  /pf/verify
    Params: server_seed_hex, client_seed, nonce, commitment_hex, outcome_hex
    Response: { valid: bool, commitment_ok: bool, outcome_ok: bool }

C9 — Demo Game Integration (entropx_game.html)

On GENERATE start: show commitment hash in HUD (truncated to first 16 chars + "...")
On GENERATE complete: show full commitment + NIST p-values
On DOWNLOAD: include provably_fair.json in the download bundle:

```json

{

"server_seed_hash": "<commitment>",

"client_seed": "<player_seed>",

"nonce": 1,

"outcome_hex": "<outcome>",

"timestamp": "<ISO-8601>",

"nist_monobit_p": 0.XXX,

"nist_runs_p": 0.XXX,

"verify_command": "python3 -c \"import hmac,hashlib; ...\""

}

```

On RESET: new session, new commitment displayed
Verification link: opens in-browser verifier using C6 algorithm

CASINO REGULATORY ALIGNMENT

| Regulatory Requirement | ENTROPX Solution |

|---|---|

| RNG output is statistically random | NIST SP 800-22 audit at generation (C1) |

| Casino cannot predict player's bet | Client seed submitted after commitment (C3, step 5) |

| Casino cannot change outcome after bet | Commitment locked before any bet (C2, step 3) |

| Player can independently verify any result | Offline HMAC verification with standard tools (C6) |

| Historical audit trail | All commitments + outcomes logged with timestamps (C8) |

| Third-party auditability | Any auditor runs the same verification function (C6) |

| Seed quality documentation | NIST p-values published with each session (C8) |

This satisfies iTech Labs GLI-19, eCOGRA audit requirements, and Kahnawake Gaming Commission technical standards — the three primary licensing bodies ENTROPX casino customers would be facing.

INTEGRATION WITH ENTROPX ENGINE

Current engine flow (entropx_engine.py):


8 sources → XOR → Knuth hash → [0,1)

Extended flow for provably fair:


8 sources → XOR → Knuth hash → [0,1) → accumulate 256 bits → server_seed
                                                                    ↓
                                                             SHA-256 → commitment
                                                             HMAC(client_seed:nonce) → outcome

The ENTROPX engine provides the server_seed. The commit-reveal layer sits ON TOP of the engine — it doesn't change the physics, it wraps the output in a cryptographic proof structure.

The game demo feeds ball-capture bytes into entropyBuffer. For provably fair:

entropyBuffer → server_seed (when buffer reaches qtyTarget)
server_seed → commitment published to player
On reveal: client verifies the buffer content would produce the same commitment

PATENT CLAIM POTENTIAL

Claim 11 (new): A method for casino-grade entropy certification comprising:

generating entropy from a physics-based multi-source system (Claim 1 system)
computing a cryptographic commitment of the generated entropy prior to any use
accepting a client-supplied seed after commitment is published
deriving round outcomes via HMAC of the committed entropy and the client seed
revealing the original entropy after round completion for offline player verification
wherein statistical quality (NIST SP 800-22) and provable fairness (commit-reveal) are simultaneously demonstrable

Why this is novel: No existing patent claims both NIST statistical certification AND commit-reveal provable fairness in a single entropy system. iTech Labs certifies quality. Blockchain gambling handles provable fairness. No one has combined physics-based NIST-certified generation with commit-reveal in one auditable unit.

This is not a separate invention — it's a method layer that lives entirely on top of Claims 1-10. Add to existing provisional or as continuation.

BUILD ORDER (when authorized)

provably_fair.py — Python module: generate_session(), derive_outcome(), reveal_session(), verify() — no dependencies beyond stdlib hmac, hashlib
Oracle Toll endpoints — 4 routes added to oracle_toll.py (C8)
entropx_game.html — commitment display in HUD, provably_fair.json in download bundle, in-browser verifier panel
Spec gap audit before commit (per feedback_mind_the_gaps)

Estimated scope: ~200 lines Python, ~80 lines HTML/JS additions. No new dependencies.

INVARIANTS

INV-01 — Commit before use. The commitment (SHA-256 of server_seed) MUST be published to the player before any game action begins. A commitment that arrives after outcome derivation is not a commitment — it's a receipt. This is the entire security property.

INV-02 — Client seed after commitment. The server_seed MUST be committed (step 3) before the client seed is received (step 5). If both arrive simultaneously, the server could have chosen server_seed to manipulate the outcome. Order is enforced, not assumed.

INV-03 — Nonce is monotonic. Nonces are integers starting at 1, incrementing by 1. No gaps, no resets within a server_seed session. A nonce is never reused with the same server_seed. Replay attack prevention.

INV-04 — Server seed never reused. Each session generates a new server_seed from the ENTROPX engine. A server_seed revealed in round N is never the basis for round N+1 or any future session.

INV-05 — Derivation function is standard. HMAC-SHA256. Not a proprietary function. Not parameterized by anything other than server_seed, client_seed, nonce. Any player with a Unix shell can verify in 10 seconds: echo -n "entropx:v1:<client_seed>:<nonce>" | openssl dgst -sha256 -hmac $(echo <server_seed_hex> | xxd -r -p)

INV-06 — ENTROPX provides the seed quality; commit-reveal provides the fairness proof. These are orthogonal. The commit-reveal works even if server_seed were generated by os.urandom(). But combining it with ENTROPX means the server_seed itself is NIST-auditable — so both proofs hold simultaneously.

INV-07 — Verification is offline. A player who saves their commitment_hex, client_seed, nonce, and outcome_hex can verify correctness at any time in the future, with any standards-compliant SHA-256/HMAC implementation, with no network access, with no trust in the server. This must remain true in all implementations.

INV-08 — The game demo proves both. When a regulator watches the Chronogeome demo, they see: NIST p-values updating in real time (quality proof) AND a commitment hash displayed before generation (fairness proof). This is the regulatory pitch. The HUD must show both simultaneously.

Filed under: ENTROPX Protocol Extension

Supplements: SPEC_ENTROPX (patent claims 1-10), SPEC_ENTROPX_DISTRIBUTION (pipeline)

Gate: T043 patent agent FIRST — ¬public disclosure until filed

κ ⊢ SPECIFIED ✓ 2026-06-15