Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing typo #4

Open
PerryGraham opened this issue Oct 9, 2023 · 1 comment
Open

Confusing typo #4

PerryGraham opened this issue Oct 9, 2023 · 1 comment

Comments

@PerryGraham
Copy link

https://github.com/alexcambose/provably-fair-example/blob/master/routes/api.js#L19

 * It doesn't return the hashed serverseed in advance, because that would
 * allow the client to generate all the rolls in advance.

Should be:

 * It doesn't return the *unhashed* serverseed in advance, because that would
 * allow the client to generate all the rolls in advance.
@PerryGraham
Copy link
Author

Hey @alexcambose,

I read everything. I understand the algorithm of provably fair. There is one part that defeats the entire purpose for me. After the bet is over, the client now has the unhashed serverseed, nonce, and original clientseed. Without knowing the combination method, or the method used to calculate a result from the hashed combination, how can the client trust that the endpoint is using the same method as what was used during the bet. Couldn't I (the developer of the server) make the verify route tell the client that those seeds honestly calculated the outcome? How does this ensure fairness to the client?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant