Editing revision 10 of FairdiceProtocol/Questions
HomePage
|
RecentChanges
|
Preferences
Editing old revision 10. Saving this page will replace the latest revision with this text.
[[Caruso]] wrote: Questions from one with the level of software sophistication on a parr with 99.999% of other online gamblers, ie. none: We have source-code verificaton and results-testing as the two options for software verification. With results-testing, the credibility of the results is the issue: are they genuine results, or faked by the casino / tester? If that is established / establisheable, then you can move forward. With this alternative, that problem is removed, but there are others (please humour me if these questions are in any way irrelevant): :DouglasReay wrote: Are these mainly relating to the post in the [http://mb.winneronline.com/showthread.html?t=15941&page=7&pp=10 thread about eCOGRA TGTR] ? ::[[Caruso]] replies: insofar as my thoughts were originally put in place with that discussion - yes. [[Caruso]] wrote: how regularly is the code tested? how is one guarenteed that the "fair" code you examine is the same code run by the operator? :DouglasReay wrote: If both the host (the operator of the casino) and the user (the player of the game) are running fairdice apps (a fairdice server in the case of the host, and a fairdice client in the case of the user), then the user doesn't have to examine the host's code, nor does the host need to examine the user's code. [[Caruso]] wrote: Is code-testing foolproof? - meaning, a code which "passes inspection" cannot then entertain the possibility that non-random numbers may still be generated? Can a "fair" code not be somehow bypassed? :DouglasReay wrote: if a result is produced by the fairdice app and the fairdice app says it has verified it, then that result is fair. A casino could try to bypass the fairdice app, by claiming to use it and not, or generating a random number from it then not using that. In which case this should be easy for the player to spot, as the player will see in the log file of the fairdice client that the result was a "4" while the casino is claiming that the roulette wheel stopped at a "7". ::[[Caruso]] replies: I think I'm making progress here: basically, both casino and customer run the application, and we can both see the numbers generated by Fairdice. At any time, I can view the log file to verify that MY Fairdice number is identical to the casino Fairdice number. While these numbers remain identical, the casino is generating random numbers; if there is a discrepancy, they are not. In other words: provided that the Fairdice software I'm running at my end is verified as good, and that both my numbers and casino numbers match, there is no possibility that the casino is not generating non-random numbers. Is that correct? :::DouglasReay wrote: Exactly! [[Caruso]] wrote: Do you consider source-code verification a better alternative to result-testing? If so, why? And the old chestnut: What guarentees is it possible to offer the consumer (me) that you are on the level and that your pronouncements may be trusted? :DouglasReay wrote: Don't trust my pronouncements. Look at the source code yourself. Or if you don't want to learn programming, find someone you do already trust, and get them to look at the source code. In fact get several. Find lots of different people, none of whom have any interests in common, and get them all to look. 9/9/04 - Caruso wrote: What stage are you at with this now, Doug? Any interest from software platforms? Or are you currently looking to get it all independently verified and haven't got to the marketing yet? Seems to me if you get a sniff from just one of the big ones the others won't have much option but to step up and be counted - always assuming that any of them actually have the desire to be subject themselves to genuine scrutiny. ---- CategoryMisc
Summary:
This change is a minor edit.
(Visit
Preferences
to set your user name.)