Open Side Menu Go to the Top
Register
Verifying Software? Verifying Software?

09-27-2014 , 01:40 AM
I'm working on a method to create a rig proof deal for a poker site.

I've already solved it where a player could actually validate that the cards couldn't be manipulated.

However, while I could keep all hole card info to a card client that would work independent of the table client and simply display the cards as an overlay, like a HUD, we would still need to trust that it didn't transmit any hole card info out unless there was a showdown.

Link to thread discussing the solution.

http://forumserver.twoplustwo.com/sh...6&postcount=23

Is it possible to attach some kind of digital signature from a regulator or auditor to an application or executable which could validate the software as being inspected and could not be modified without losing or faking that signature?

My question is if there were some way to monitor the card client traffic or verify the code such that it only could transmit data when it's supposed to?

Perhaps an uncompiled text script file using something like AHK that users could run while not being able to modify the code?
Verifying Software? Quote
09-27-2014 , 07:37 AM
why re-invent the wheel

"provably fair" has already been accomplished on the bitcoin 'dice' gambling sites
Verifying Software? Quote
09-28-2014 , 03:03 PM
Quote:
Originally Posted by greg nice
why re-invent the wheel

"provably fair" has already been accomplished on the bitcoin 'dice' gambling sites
I'll look it over, can you provide a link?
Verifying Software? Quote
09-28-2014 , 03:26 PM
Never mind, I found it. I haven't read through it all but it sounds pretty close to the same method that I came up with, at least in part.

Thanks for the heads up. Still reading through it.
Verifying Software? Quote
09-28-2014 , 05:25 PM
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.
Verifying Software? Quote

      
m