Open Side Menu Go to the Top
Register
Programmers, help fight the UIGEA from the bottom up. Programmers, help fight the UIGEA from the bottom up.

11-19-2007 , 05:02 PM
How about this: cards can come (encrypted and digitally signed) from a third party.

So the system could be configurable to use:
A) Someone in the game
B) Some random person from the P2P network
C) One or more trusted 3rd parties (I can see a business built solely around providing a stream of random cards)

So in a game with lots of trust among players you use A, in a game with no trust you could use C, and if you're somewhere in between you might use B. Obviously when you sit at the table you have to agree to the provider.
Programmers, help fight the UIGEA from the bottom up. Quote
11-20-2007 , 01:05 AM
One point, only one PC has to handle anything more robust that the clients we already download from the sites.

The random number generator is a function of how well you guys write the server program.

Internet connections can apparently handle a couple of dozen games at once if I am to believe the multitablers around here.

Again, this whole thing is supposed to be a small network of a dozen or so players up to maybe half a dozen tables.

I see my coworkers all playing Halo against each other at the same time on plain vanila PC's. That has to be a whole bunch more computer intensive.

You guys write good solid poker software, I don't think there are to many more issues. My wife will be the banker. She is honest to a fault.

Tuff
Programmers, help fight the UIGEA from the bottom up. Quote
11-20-2007 , 01:27 AM
Tuff,

did you read my proposed system n IG forum?

Are you familiar with the scale of current CounterStrike etc. game servers out there?

dave.
Programmers, help fight the UIGEA from the bottom up. Quote
11-20-2007 , 11:41 AM
Yes, I read it.

I didn't understand most of it. I am not a gamer nor much of a computer geek.

But if there is a workable model, that suits me fine. Just make it work.

Tuff
Programmers, help fight the UIGEA from the bottom up. Quote
11-20-2007 , 12:11 PM
.. when its open source, there will be hacks.
.. when its not open source, who knows there will be no superuser or keylogers trojas or whatever.

-> as soon as money comes into play p2p, mesh/private networks wont work.


edit : my biggest probs : software rngs are exploitable, encryption is not guaranted.
Programmers, help fight the UIGEA from the bottom up. Quote
11-20-2007 , 01:11 PM
are you the real tuff fish (sorry to bother) ?

If so, thank you very much for untilting me a lot of times
Programmers, help fight the UIGEA from the bottom up. Quote
11-20-2007 , 02:10 PM
Quote:
If so, thank you very much for untilting me a lot of times
I also love his video!

Basically when it's running in the background I play like a god. It should be banned as an unfair advantage



(sorry Tuff Fish but that video really rocks! )
Programmers, help fight the UIGEA from the bottom up. Quote
11-20-2007 , 04:36 PM
Glad I can brighten your days.

Sometimes when I hear myself, I simply cannot believe I actually did all that.



Tuff
Programmers, help fight the UIGEA from the bottom up. Quote
11-21-2007 , 04:52 PM
After going back and forth a couple of times with one of the ace programmers here at work, (who's hobby is computer security ) I now have complete confidence that we can solve the individual server security question. There is a methodology to ensure that the code running any of our individual servers has not been tampered with.

Therefore, if a homegame is running "my" implementation of the open source poker software, the players will know it is safe and that someone has not gotten into it and is now looking at your hole cards. So, if you trust "me" then you will know whatever home game is running "my" software is honest. At least as far as the poker site program is concerned.

"My" software will be running play money games. (your choice of play money rake or not) If and how you handle turning play money games into real money games is left to the individual homegame operators.

Schemes to turn play money into real money is another thing keeping my mind busy. The thing is not to fool the DOJ, it is to do so in a way that they can't do anything about it.

Tuff
Programmers, help fight the UIGEA from the bottom up. Quote
11-21-2007 , 07:47 PM
Quote:
if a homegame is running "my" implementation of the open source poker software, the players will know it is safe and that someone has not gotten into it and is now looking at your hole cards.
100% wrong.

Post this in the Software Forum I bet there are people capable of reading "your" hole cards if the server is running on their computer (and it does NOT have to be open-source).
Ask them cause they are way better about computers but I assure you you are wrong on this.
Programmers, help fight the UIGEA from the bottom up. Quote
11-21-2007 , 08:12 PM
This IS the software forum...

Tuff

And you are wrong. You won't be able to decompile or modify the software at all, or run a debugger in parallel etc. If you try it, the server won't deal. Plus, your buddies get a message about what you are trying. Next comes the knee breaking.
Programmers, help fight the UIGEA from the bottom up. Quote
11-21-2007 , 09:04 PM
Turns out someone's already thought about shuffling and dealing without a trusted third party using various encryption schemes:
http://www.nongnu.org/libtmcg/
http://en.wikipedia.org/wiki/Mental_poker

No need to worry about people decompiling the software!
Programmers, help fight the UIGEA from the bottom up. Quote
11-21-2007 , 09:28 PM
Quote:
Turns out someone's already thought about shuffling and dealing without a trusted third party using various encryption schemes:
http://www.nongnu.org/libtmcg/
http://en.wikipedia.org/wiki/Mental_poker

No need to worry about people decompiling the software!
Oh my, FANTASTIC post Nortonesque

Going to have to spend some time reading over these!

Tuff:

Quote:

You won't be able to decompile or modify the software at all, or run a debugger in parallel etc. If you try it, the server won't deal. Plus, your buddies get a message about what you are trying. Next comes the knee breaking.

No.

Nonononononono!

Attempting to prevent people using decompilers etc. is futile, and misguided.

The software must be robust enough that use of a debugger is of no advantage to the user. Security by obscurity =/= security, to trot out an old (but very true) cliche.

Quote:

(and it does NOT have to be open-source)

But it *should* be, otherwise how would anyone be able to trust it?
Programmers, help fight the UIGEA from the bottom up. Quote
11-21-2007 , 11:53 PM
Quote:
Quote:
Turns out someone's already thought about shuffling and dealing without a trusted third party using various encryption schemes:
http://www.nongnu.org/libtmcg/
http://en.wikipedia.org/wiki/Mental_poker

No need to worry about people decompiling the software!
Oh my, FANTASTIC post Nortonesque
Great find!

Quote:
Quote:

You won't be able to decompile or modify the software at all, or run a debugger in parallel etc. If you try it, the server won't deal. Plus, your buddies get a message about what you are trying. Next comes the knee breaking.

No.

Nonononononono!

Attempting to prevent people using decompilers etc. is futile, and misguided.
Yep, this is a hopeless method of trying to protect stuff. If your friend at work thinks that software can be protected from snoopers, then I'm afraid he's wrong.

If he were correct, then he could make himself a billionaire overnight because the same method could be used to protect software from crackers and to this date no such "uncrackable" software exists.

Juk
Programmers, help fight the UIGEA from the bottom up. Quote
11-22-2007 , 12:19 AM
Tuff,

The software does have to be open source. Unless you're going to pay them out of your non existent poker winnings, the only way this thing will ever get built, improved and maintained is with community collaboration.

Great find on the secure shuffling algorithm. However, there was a list of patents that this code may violate:

Quote:
Here we list known patents which are related to used techniques or provided
functionalities of this software. We stress that in some countries the usage
of LibTMCG may violate the claims of these patents and thus is prohibited
by law. However, I am not a lawyer ...

* EP0384475 (1990-08-29, SCHNORR CLAUS PETER)
Method for subscriber identification and for the generation and verification
of electronic signatures in a data exchange system

* US4995082 (1991-02-19, SCHNORR CLAUS P)
Method for subscriber identification and for the generation and verification
of electronic signatures in a data exchange system

* JP3001629 (1991-01-08, KURAUSU PEETAA SHIYUNORU)
METHOD FOR GENERATING AND CONFIRMING MUTUAL IDENTIFICATION AND SIGNATURE
OF SUBSCRIBER IN DATA EXCHANGE SYSTEM

* US6077161 (2000-06-20, WISLER JAMES M)
Multiplayer card games having card plays to foundations

* WO0173694 (2001-10-04, NEFF C ANDREW, VOTEHERE INC)
VERIFIABLE, SECRET SHUFFLES OF ENCRYPTED DATA, SUCH AS ELGAMAL ENCRYPTED
DATA FOR SECURE MULTI-AUTHORITY ELECTIONS

* US2002007457 (2002-01-17, NEFF C ANDREW)
Verifiable, secret shuffles of encrypted data, such as elgamal encrypted
data for secure multi-authority elections

* WO02056230 (2002-07-18, NEFF C ANDREW et al., VOTEHERE INC)
ELECTRONIC VOTING SYSTEM

* US2002078358 (2002-06-20, NEFF C ANDREW et al.)
Electronic voting system

* US2002103029 (2002-08-01, FINLAYSON SCOTT; MULCAHY STEPHEN; LOW MICHAEL)
Multiplayer gaming

* EP1259024 (2002-11-20, FURUKAWA JUN, NIPPON ELECTRIC CO)
Certified shuffle-decrypting system, certified shuffle-decrypting method
and certified shuffle-decryption verifying method

* JP2002344445 (2002-11-29, FURUKAWA JUN, NIPPON ELECTRIC CO)
SHUFFLE-DECODING SYSTEM WITH CERTIFICATION AND METHOD THEREFOR, AND
SHUFFLE DECODING VERIFICATION METHOD

* US2002181702 (2002-12-05, FURUKAWA JUN, NIPPON ELECTRIC CO)
Certified shuffle-decrypting system, certified shuffle-decrypting method
and certified shuffle-decryption verifying method

* BE1014397 (2003-10-07, LAUREYSSENS DIRK)
Online card game, played using physical or virtual cards via e.g.
computer, hand held device or television

* US2005028009 (2005-02-03, NEFF C ANDREW, VOTEHERE INC)
Verifiable secret shuffles and their application to electronic voting

* WO2005093671 (2005-10-06, SALOMONSEN GORM, GROTH JENS, CRYPTOMATHIC AS)
ELECTRONIC VOTING SYSTEMS

? Electronic Card Games in general:
http://v3.espacenet.com/results?sf=a&amp...p;=&=&=

? Secret Electronic Voting in general:
http://v3.espacenet.com/results?sf=a&amp...p;=&=&=

Finally, I want to say I am disappointed but I have not lost either hope.
Programmers, help fight the UIGEA from the bottom up. Quote
11-22-2007 , 12:30 AM
The software CAN be protected.

The individual poker game servers will be worthy of trust.

No dishonest site operator will be able to mess with the code without immediate detection and notification of the other players at the site.

There can be a whole universe of poker sites out there ranging from one table sites to many table sites..... depending.

The method does not violate any patents.

My co-worker may well be a millionaire someday.

Tuff
Programmers, help fight the UIGEA from the bottom up. Quote
11-22-2007 , 12:38 AM
Quote:
The software CAN be protected.
I'm sorry, but is just wrong. No piece of software can be protected from snooping as the very definition of "software" means that it has to be executed on a machine and if the machine can understand it then so can a human.

You can make it very hard, but their will always be somebody with the dedication and know-how to get round whatever you try.

Juk
Programmers, help fight the UIGEA from the bottom up. Quote
11-22-2007 , 12:42 AM
Quote:
Tuff,

The software does have to be open source. Unless you're going to pay them out of your non existent poker winnings, the only way this thing will ever get built, improved and maintained is with community collaboration.

Great find on the secure shuffling algorithm. However, there was a list of patents that this code may violate:

Quote:
Here we list known patents which are related to used techniques or provided
functionalities of this software. We stress that in some countries the usage
of LibTMCG may violate the claims of these patents and thus is prohibited
by law. However, I am not a lawyer ...

* EP0384475 (1990-08-29, SCHNORR CLAUS PETER)
Method for subscriber identification and for the generation and verification
of electronic signatures in a data exchange system

* US4995082 (1991-02-19, SCHNORR CLAUS P)
Method for subscriber identification and for the generation and verification
of electronic signatures in a data exchange system

* JP3001629 (1991-01-08, KURAUSU PEETAA SHIYUNORU)
METHOD FOR GENERATING AND CONFIRMING MUTUAL IDENTIFICATION AND SIGNATURE
OF SUBSCRIBER IN DATA EXCHANGE SYSTEM

* US6077161 (2000-06-20, WISLER JAMES M)
Multiplayer card games having card plays to foundations

* WO0173694 (2001-10-04, NEFF C ANDREW, VOTEHERE INC)
VERIFIABLE, SECRET SHUFFLES OF ENCRYPTED DATA, SUCH AS ELGAMAL ENCRYPTED
DATA FOR SECURE MULTI-AUTHORITY ELECTIONS

* US2002007457 (2002-01-17, NEFF C ANDREW)
Verifiable, secret shuffles of encrypted data, such as elgamal encrypted
data for secure multi-authority elections

* WO02056230 (2002-07-18, NEFF C ANDREW et al., VOTEHERE INC)
ELECTRONIC VOTING SYSTEM

* US2002078358 (2002-06-20, NEFF C ANDREW et al.)
Electronic voting system

* US2002103029 (2002-08-01, FINLAYSON SCOTT; MULCAHY STEPHEN; LOW MICHAEL)
Multiplayer gaming

* EP1259024 (2002-11-20, FURUKAWA JUN, NIPPON ELECTRIC CO)
Certified shuffle-decrypting system, certified shuffle-decrypting method
and certified shuffle-decryption verifying method

* JP2002344445 (2002-11-29, FURUKAWA JUN, NIPPON ELECTRIC CO)
SHUFFLE-DECODING SYSTEM WITH CERTIFICATION AND METHOD THEREFOR, AND
SHUFFLE DECODING VERIFICATION METHOD

* US2002181702 (2002-12-05, FURUKAWA JUN, NIPPON ELECTRIC CO)
Certified shuffle-decrypting system, certified shuffle-decrypting method
and certified shuffle-decryption verifying method

* BE1014397 (2003-10-07, LAUREYSSENS DIRK)
Online card game, played using physical or virtual cards via e.g.
computer, hand held device or television

* US2005028009 (2005-02-03, NEFF C ANDREW, VOTEHERE INC)
Verifiable secret shuffles and their application to electronic voting

* WO2005093671 (2005-10-06, SALOMONSEN GORM, GROTH JENS, CRYPTOMATHIC AS)
ELECTRONIC VOTING SYSTEMS

? Electronic Card Games in general:
http://v3.espacenet.com/results?sf=a&...p;=&=&=

? Secret Electronic Voting in general:
http://v3.espacenet.com/results?sf=a&...p;=&=&=

Finally, I want to say I am disappointed but I have not lost either hope.
That sucks and so does the whole idea of allowing software patents IMO...

Is their no country without IP laws anymore? Indonesia used to have no IP laws until fairly recently, but I think they do now.

Juk
Programmers, help fight the UIGEA from the bottom up. Quote
11-22-2007 , 12:47 AM
Quote:
Quote:
The software CAN be protected.
I'm sorry, but is just wrong. No piece of software can be protected from snooping as the very definition of "software" means that it has to be executed on a machine and if the machine can understand it then so can a human.

You can make it very hard, but their will always be somebody with the dedication and know-how to get round whatever you try.

Juk
You are attacking the wrong problem.

But keep up the good work all. All along here, folks are defining and refining the solutions to the problem.

The security problem is solved unless somebody shows a problem we haven't mitigated. Keep thinking, objections are good.

Payments and who and how are another problem, but not necessarily a software one. We will never be able to "slip one by" the DOJ, but we may be able to do things in such a manner that they can't do anything about it.

Tuff
Programmers, help fight the UIGEA from the bottom up. Quote
11-22-2007 , 01:03 AM
Quote:
That sucks and so does the whole idea of allowing software patents IMO...
I'm generally in favor of patents when the topic is sufficiently complex and innovative.

But patenting an algorithm that a math graduate can figure out in several hours is so unbelievable wrong, especially when that algorithm may be the only possible solution to a given problem.
Programmers, help fight the UIGEA from the bottom up. Quote
11-22-2007 , 01:10 AM
Quote:
Quote:
Quote:
The software CAN be protected.
I'm sorry, but is just wrong. No piece of software can be protected from snooping as the very definition of "software" means that it has to be executed on a machine and if the machine can understand it then so can a human.

You can make it very hard, but their will always be somebody with the dedication and know-how to get round whatever you try.

Juk
You are attacking the wrong problem.

But keep up the good work all. All along here, folks are defining and refining the solutions to the problem.

The security problem is solved unless somebody shows a problem we haven't mitigated. Keep thinking, objections are good.
If your security stands on the belief that some software can be made "unsnoopable" then I'm afraid it's just not going to work and as soon as money is involved all the smartest crackers in the world will be working round the clock to find a method to circumvent whatever you have tried. The only really secure method is to use some decentralized cryptographic algorithm as outlined in the other post.

I think this whole idea is an interesting one, but is fundamentally flawed. Assuming that a P2P poker client was created and a bank (or other trusted institution) agreed to hold player's money in such a way as to allow other players to confirm each other's balances (so as not to allow balance "faking"), then I have to ask myself would I play on such a system myself?

Sadly, I don't think I would other than for heads up matches. I think for HU matches then a system like this could be trusted 100%, but as soon as you add multiple people into the equation then how can you be sure they are not colluding against you?

One option would be to have hand histories that revealed all of the mucked cards after each hand was over. This would change the fundamental way poker is played, but at least (in theory) then each player could see if they were being colluded against. I'm sad to say again that I still wouldn't play even with this addition, as I'm quite sure that somebody smart enough could collude in a very clever way that would make detection almost impossible.

So in conclusion: I think this makes for a very interesting academic idea and could possibly work in practice for heads up play, but I don't think you can ever secure it properly against collusion for multi-player games.

Juk
Programmers, help fight the UIGEA from the bottom up. Quote
11-22-2007 , 01:33 AM
I think you'd be far better working out the details of the payment system first, and getting back to us once you've solved that. Not "just make it work", but the actual details of HOW it will work, what the costs will be, what the deposit options will be, how it'll interact with the p2p software to guarantee payment, how you'll identify players to process payment, etc. I think if you do that, you'll see why your idea is a non starter - or at the very least, not superior to a fixed, centrally managed server.

As an engineer I'm sure you realize that most radical ideas look fine on paper but fall down in the details.
Programmers, help fight the UIGEA from the bottom up. Quote
11-22-2007 , 02:42 AM
The algorithm also is very susceptible to someone dropping out, so it may be somewhat academic.

Quote:
I think this whole idea is an interesting one, but is fundamentally flawed. Assuming that a P2P poker client was created and a bank (or other trusted institution) agreed to hold player's money in such a way as to allow other players to confirm each other's balances (so as not to allow balance "faking"), then I have to ask myself would I play on such a system myself?
Another problem would be for the bank to confirm the game's actual outcome.

Quote:
Sadly, I don't think I would other than for heads up matches. I think for HU matches then a system like this could be trusted 100%, but as soon as you add multiple people into the equation then how can you be sure they are not colluding against you?
Not overly dissimilar from the current situation though.

The system I'm envisioning would allow anyone to run a table and select a card provider (which could be themselves, or some trusted third party, or something else a la mental poker). So you could imagine:

A high trust environment -- like PS or FTP, where a money holder sets up the table, and only allows customers to play, and has total access to the results.

A low trust environment -- where it's play money and it runs off one of the player's machines.

Somewhere in between -- like a homegame, or something else. This would be the really intriguing place to watch, and see what interesting payment systems pop up.
Programmers, help fight the UIGEA from the bottom up. Quote
11-22-2007 , 02:53 AM
Quote:
Quote:
Sadly, I don't think I would other than for heads up matches. I think for HU matches then a system like this could be trusted 100%, but as soon as you add multiple people into the equation then how can you be sure they are not colluding against you?
Not overly dissimilar from the current situation though.
I think that having a 3rd-party take care of the collusion detection (and bot detection) using their own unpublished methods is probably more likely to put off colluders (and botters). Perhaps, I'm wrong for thinking like this though.

Juk
Programmers, help fight the UIGEA from the bottom up. Quote
11-22-2007 , 03:19 AM
OK -- picture the high trust environment above but with a program that the money holder requires its customers to run, which checks for botting software, collusion, etc. We should be able to replicate the status quo (if the status quo is indeed high trust).

I guess basically what I'm envisioning is leveling the playing field for poker software and having people compete on trust environments (payment systems, deal fairness, game fairness). And if that competition never materializes, well, we've got a spiffy p2p system for free money games I guess.
Programmers, help fight the UIGEA from the bottom up. Quote

      
m