search

kripod / provably-fair

Tools for creating and verifying provably fair games.
https://bitcointalk.org/index.php?topic=1785340
MIT License
18 stars 3 forks source link

Create an initial specification #1

Open kripod opened 7 years ago

kripod commented 7 years ago

Besides the core API reference, there should be a "plain English" (non-technical) introductory text, and more details for advanced users/adopters.

vladignatyev commented 7 years ago

Hi, it's dicedicedice, I sent a message to you on BitcoinTalk with an example of spec.

Should the initial specification you're talking about in this issue cover the core principles of provably fair gambling and it's difference to classical gambling? Should it explain what is a "provably fair" at a glance, and how business of common (online) casinos differ from provably fair casinos, how provably fair changes business landscape here? Do you have an idea for structure of the initial specification? Could you please share your thoughts?

For example, "provably fair" is a very simple idea in it's core, but it is a rule changer for the whole gambling world: for casinos, for players, for regulators and governments, for society. Sometimes it may be referred as "transparent", "honest", but in some cases it is a stereotype, because even provably fair games keep the place for tricking on the casino side.

Also, I think that understanding of "provably fair" concept itself could be related to understanding some principles of cryptography, namely the structure and operating of hashing algorithms and underlying cryptography primitives. How it should be covered?

For example, it's (hopefully) required to cover such topics as SHA-2, Avalanche effect, Length expansion attack, HMAC/Hash difference, and a plenty of other good topics with sometimes very hairy maths in order to provide correct and reliable specifications and examples.

kripod commented 7 years ago

@vladignatyev Thank you for all the thoughtful ideas! I am open about the format of the specification, but the main goal is to keep it short and simple with clearly understandable analogies and illustrations. All the docs/specs should be written in .md format.

For people who are more involved in cryptography and computer science in general, an appendix with more details could be made, but covering topics like the avalanche effect is - in my opinion - out of the scope of this project. Using HMAC instead of keyed hashes is an important detail, though, and should be mentioned somewhere.