Quote:
Originally Posted by greg nice
why re-invent the wheel
"provably fair" has already been accomplished on the bitcoin 'dice' gambling sites
After reading a bit more, It seems that poker is not included as an option though I could be mistaken.
I can understand why this would be the case. While I did come up with method to provide proof that a deal could not have been manipulated fairly quickly, providing a method to prove a site could not know your hole cards or future board cards is a much more difficult problem to solve, especially in a practical manor, e.g. without needing to provide a new set seeds every hand. Without this a "Super-User" exploitation is still possible.
BTW, I stopped investigating this method just in case sites are copyrighting their methods. I didn't want any other method to influence my own results to somehow infringe on their copy-rights.
My intention is to create a method that could be used by any site and possibly establish a standard.
Back to the "Super-User" example. The last step to preventing a super user would be the issue of a local card client being difficult to not be blocked from knowing your cards since it needs to be able to display your cards.
It could be possible by using some kind of encryption scheme for naming the graphics files so the client only knows it's showing pictures of cards but not necessarily the exact card values. I'd need to investigate this further.
However, an easier solution is just to make sure the client does not transmit hole cards or prematurely display board cards by making the actual code transparent.
Example:
Assuming the card client receives only cards that can be decrypted specific to the user which was already solved in the other thread we would still require a simple card client that's independent from the table client such that it can decrypt and display cards at the correct times but only release this information via: i/o to a file or display, Rx/Tx to another client or server, or graphically displaying of cards, only as it is correct to do so.
To know this was true, we would need to see the actual code. But to protect the game we should not be able to modify the code either.
So this could be accomplished by using a hashing algorithm to ensure the user compiled file is identical to a known file that wasn't modified.
This doesn't need to change the end user experience since you could simply make it an advanced option that would compile the file for you if unchecked or allow you to copy and save the code before you compile it yourself. This would show you that code you review is in fact the executable that is displaying your cards.
BTW, the card client would need to be the master that would actually be loading the table client and not the other way around to complete the verification.