Absolutely! Here’s how we do it:
Before each spin, we generate a random number (0..36) and a salt, then publish the SHA-256 hash of num:salt
After the spin, we reveal the salt, so you can re-hash the exact same num:salt combination.
If the hash matches what we published before the spin, you know the result couldn’t have been altered.
Then there is a problem with your provably fair engine because if you don't like the result you can select a new random number to mix it with that salt.
Let's say users are betting on 11, and your engine select a random number with the salt and the result of that gives 11, then you can try with another random number and get a number different than 11. The fact that you apply a random number to the provably fair engine is tricky because you can reroll that number until you get the desire result and then publish the sha-256.
For me, your engine isn't provably fair, sorry.
Absolutely! Here’s how we do it:
Before each spin, we generate a random number (0..36) and a salt, then publish the SHA-256 hash of num:salt
After the spin, we reveal the salt, so you can re-hash the exact same num:salt combination.
If the hash matches what we published before the spin, you know the result couldn’t have been altered.
Then there is a problem with your provably fair engine because if you don't like the result you can select a new random number to mix it with that salt.
Let's say users are betting on 11, and your engine select a random number with the salt and the result of that gives 11, then you can try with another random number and get a number different than 11. The fact that you apply a random number to the provably fair engine is tricky because you can reroll that number until you get the desire result and then publish the sha-256.
For me, your engine isn't provably fair, sorry.
Thanks for your thorough analysis! Let me clarify how our provably fair system works to ensure integrity:
Secure Salt Generation: We use a 16-character hexadecimal salt (64 bits of entropy), making it virtually impossible to find another salt that produces the same SHA-256 hash. This level of security ensures that the salt cannot be manipulated to achieve a desired outcome.
Hash Commitment Before Bets: We publish the hash of num:salt before any bets are placed. This means the outcome is locked in and cannot be altered based on the bets received. Once the hash is out there, we can't change the num or salt without invalidating the hash.
Immutable Results: After the spin, we reveal the original salt, allowing anyone to verify that the hash matches the num:salt combination. This transparency ensures that the result was not tampered with after bets were placed.
Mathematical Impracticality of Manipulation: Given the strength of SHA-256, attempting to find a different salt that results in the same hash is computationally infeasible. This makes it practically impossible to reroll the number to favor certain outcomes.
Security Assurance: If anyone were to discover a way to manipulate the salt and hash to influence outcomes, we'd be very interested in learning about it and would gladly offer a bounty for such findings to further improve our system.
Our focus is on maintaining a fair and transparent gaming environment for Bitcoiners, leveraging the security of the Lightning Network and robust cryptographic practices. We appreciate your scrutiny and hope this clarifies our commitment to provably fair gaming!
— The LN Roulette Team