Jump to content


Popular Content

Showing most liked content since 02/22/2018 in all areas

  1. 1 point
    Note: This is a poorly written stub, I'll edit it as I have the more time. The core idea of most provably fair schemes is the idea the server has committed to a value, and allowing the user to verify this. (There is also a separate aspect of provably fair which is interpreting the commitment as a fair result, which includes things like mixing in a client seed). So the simplest commitment scheme is: Server gives user a hash of their seed User places bet. Server reveals result, and their seed. This has a few advantages: Super simple Can verify each bet as soon as it's made But comes with some significant disadvantages User needs to fully trust the client software (e.g. pick fully randomized client seeds, verifying bets) or: User needs to manually randomize each bet, and verify each one. A very tedious and painful process Because of the pain in manual verification, the current industry standard is to do something a bit more human-friendly Server gives user a hash of their seed User places N bets, each with an increasing nonce Server reveals the seed only on demand, allowing user to batch verify all bets. (And goes back to step 1) But this is not without it's disadvantages too: Quite difficult for automated verification (especially if there's multiple clients betting) If you want to verify, you need to go through the seeding process again So I think we can do a little better. The simplest (but not practical to implement) solution, would be: The server generates a seed The server hashes the seed 10 million times, storing each intermediate result Each time a user bets, we remove the last element from this "hash chain" and use for provably fair This has some nice properties: It's reasonably simple It allows instant verification It allows batch verification (and doesn't require reseeding) And only one significant downside for the user: There's a finite amount of games the user can play (e.g. 10M) before they need to reseed The main issue with this scheme, is it's not very practical for the server to be generating and storing large hash chains on a per-user basis. However, I believe we can have our cake and eat it too! Instead of a hashchain, we actually use a tree. This is best explained here: https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt From the users point-of-view, it's largely the same as a hash chain except: Way more complexity But from the servers perspective, it is pretty nice. The server only needs a single seed per user, and can calculate any result with log n [Where n is the amount of possible games the seed is useful for) hashes. So for example, if you want the seed to work with 1M games, the server just needs to do up to 20 hashes per bet.