# Provably Fair ### Introduction When a new game starts, a bullet is placed in a random chamber of the revolver. Each time a user pulls the revolvers trigger, RNG Gaming Bots check whether the bullet is in the current chamber being fired. The bullet position in the revolver chamber is generated at the start of the game. The position of the bullet in the revolver chamber must be publicly available at the start of the game. Otherwise, if the bullet position were published at the end of the game, it would be impossible to prove that the bullet position in the revolver chamber isn't being manipulated. However, if the bullet position in the revolver chamber were to be published at the start of each game, each player would know exactly where the bullet is, and the game would be broken. Therefore, the bullet position in the revolver chamber must be encrypted and published at the start of each game, while the keys to decrypt the bullet position must be published at the end of the game. But how can RNG Gaming prove that the number is not predetermined at the start of the game? And how can RNG Gaming prove the number has been randomly generated? And how can RNG Gaming prove that the bullet position has not been manipulated as the game progresses? ### Randomness and Fairness RNG Gaming uses a Verifiable Random Function (VRF) to generate random numbers for each game. These random numbers can be encrypted and published at the start of the game. At the end of the game, the decryption key, as well as mathematical proofs that the number was in fact randomly generated and untampered during the game are published and saved onto the Solana blockchain. When the game ends, the bot sends the following as part of an `end_game` transaction. **alpha** * **Description**: `alpha` is created by concatenating the UNIX time with an array of each player's bets. * **Why It Is Important**: `alpha` ensures that the `proof` and resulting `beta` are specific to the particular game instance. **salt** * **Description**: `salt` is a randomly generated string using pythons secrets token hex library. * **Why It Is Important**: `salt` adds an additional layer of randomness, ensuring that even if the `seed` and `proof` are reused, the resulting `beta` will be different. This prevents predictability and ensures each game's outcome is unique. **seed\_hash** * **Description**: `seed_hash` is the hashed value of randomly generated `seed` and `salt`, using PBKDF2 HMAC with a specified number of iterations. The `seed` itself is not revealed to maintain security, and is not needed for cryptographic validation. The `seed` is generated using pythons secrets token hex library. * **Why It Is Important**: `seed_hash` allows for deterministic regeneration of the `beta` value during verification without exposing the raw seed. It provides a secure way to tie the randomness to a specific game instance while maintaining the seed's privacy. **proof** * **Description**: `proof` is a digital signature generated for a random number `beta` using a random private key and the input message `alpha`. * **Why It Is Important**: `proof` ties the random number to the private key and the specific game parameters `alpha`. It provides cryptographic proof that the number was generated legitimately and has not been tampered with. **beta** * **Description**: `beta` is the randomly generated number in hexadecimal format. This number is converted into an integer and modulo'ed with the size of the revolver chambers. * **Why It Is Important**: `beta` is derived from a `seed hash`, `salt`, and `proof`, ensuring it is deterministic yet unpredictable. It serves as the basis for determining the bullet's chamber index, providing randomness and fairness in the game. **public\_key** * **Description**: `public_key` is the public key of the randomly generated private key. Each game has its own public and private key pair. * **Why It Is Important**: `public_key` is used to verify the digital signature `proof`. It ensures that the proof was generated by the corresponding random private key, maintaining the integrity and authenticity of the game's setup. The VRF implementation ensures that the random number `beta` is not predetermined by using a cryptographically secure, randomly generated `seed` and `salt`, combined with a unique input message `alpha` and generating a `proof` using a random private key. The resulting bullet index is random due to the unpredictable nature of the `seed` and `salt`, and its integrity is verified through public key validation of the `proof` and consistent recalculation of `beta`, preventing any manipulation. This process guarantees fairness and transparency in the game's outcome. ### VRF Implementation For more details regarding exact implementation and more in-depth documentation, please visit the following Github repository. {% embed url="" %}