Original post from peer review below (since only one thread per site is allowed):
8Bet.io is a player-powered crypto gambling platform about to launch a 100% return cooperative lottery. We've published a blog post describing the Provably Fair model that uses the Bitcoin blockchain for the random number generator, see here:
https://8bet.io/blog/how-it-all-works/Extract below, for convenience. We'd welcome peer reviews of this model, with any constructive criticism of this method, thoughts on possible exploits, concerns etc. Thanks!
The 8Bet Lottery results are generated as follows:
1. At the start of the game (before any tickets are sold) a server seed is randomly generated by the server.
2. This server seed is then hashed using SHA256 and the seed hash is then published on the game for all to see. Because this hash is public from the start of the game, the original random server seed can not be modified in any way.
3. Players then buy tickets for the game until the time of the draw.
4. At the time of the draw, ticket buys are closed and the game waits for the next block to be mined on the Bitcoin blockchain. When this happens, the game takes the block hash from this next block.
5. The server seed and the block hash are then joined together and this concatenated server seed + block hash is hashed using SHA256. This hash is then used as the RNG seed for the random number generator.
6. The lottery results (6 lottery numbers) are then randomly generated by the well-known Mersenne Twister random number generator.
_____________________________________________
Thank you! Both excellent points!
Agreed that making the ticket list public prior to the draw is an important improvement to the provably fair model - so yes, we'll take this on board and add this feature to an upcoming release. As a quick first thought on this, we'd also ensure that the ticket numbers chosen on each ticket remained private (hash with salt maybe) so player privacy was maintained (ensuring an attacker couldn't link tickets together for players choosing the same lucky numbers in each draw, or some other form of anti-privacy analysis) - but it would still be indisputably provable that the numbers on the winning ticket were generated and bought prior to the draw.
Regarding miner collusion - yes, this was a concern of ours too. In fact, we had first implemented a complicated results generation model that had a list of random indexes to transactions within the next block, and generated the RNG seed from the least significant bits of the transactions at these indexes. However, we discarded this as being overly complicated to explain or for the average player to have to step through to prove. We opted for the block hash in favour of usability and ease of understanding - but your point on miner collusion possibility still needs addressing.
It would actually be interesting to calculate just how much of the global hashrate you'd have to control in order to make this sort of collusion viable, and how this would relate to the size of the jackpot - where the tipping point would be to make discarding a block feasible. We'll take this one to the whiteboard and mull it over some - as you point out, in the early stages with jackpots smaller than the block reward this sort of collusion is idiotic so less of a concern. However with time we expect jackpots to significantly exceed block rewards, so we will aim to have a solid solution for this well before then. Watch this space!
Thanks again for the great feedback!