To make it brief, it all began with a giveaway discussion where I proposed a few tweaks for better verifiability. I’m curious if this method is solid or if I overlooked anything.
The entropy is low; using only the last two numeric digits provides only 100 possible outcomes. This limited range increases the likelihood of participants predicting the result, especially on a large scale
It works but a better way that also makes cheating (by both sides) much harder is this:
1. Server chooses a random entropy and keeps it private.
2. Server releases the hash of that entropy (so that server can not change the seed later, also SHA256 is used because in step 5 we use SHA512)
3. One or more future block heights is chosen and announced as the additional entropy to be used.
4. The list of participants is locked with each one having an index (from 0 to max count -1)
5. The algorithm to derive the result is publishes (the steps here).
[Now that everything is locked and can not change, we wait for the blocks to be mined]
6. Compute HMACSHA512 using the 3 block hashes (concatenated) and the actual seed from step 1 as the key to derive a 512-bit entropy.
7. Server publishes the entropy/seed from step 1 for everyone to verify
8. Select bits from step 6 to get your integers. Something like this:
Step 6 and 8 can be changed to use a different KDF that derives keys and converts them to integers in a loop, but the basic idea of it is what I described here.
Thanks a lot for explaining it in such a detailed manner to a curious noob like me. I get that increasing entropy injects more randomness into the process as you and @ThewsyRum pointed out.
It is a great learning for me. Thanks once again.
Locking this topic as I get what I wanted and keeping this short and straight for anyone interested.