There are a number of serious concerns about a P2P poker client. If I approached this directly and didn't know much about how people exploit games, I would provide full server functionality along with the client (which is fairly normal in regular games). This would mean that the host server would have the ability to ask the main server which contains account balances to move their chips onto the table (you can see why that would be a very dangerous thing). Then there's the whole deck drawing -- would you like to trust the host to not find a way to stack the deck? There are so many flaws with this method and so many gaping holes in security here.
If I had a little bit of knowledge about cheating, I'd make it so the main server handles the original withdraw and then passes some value to the server. This still requires
absolute trust in whoever is the host to not just take your chips right then and there and communicate to the main server you lost everything and the host won everything. If the host was a little more clever maybe he/she would just take a chip here and there hoping no one would notice.
Finally, if I absolutely had to do P2P but wanted to the best I could to secure it, the only way to do this P2P system would be to run the host server asynchronous to a duplicate instance of the game on the main server. This would mean that even a cheating host would only be able to tell the main server what happened, but the main server would overrule. The P2P aspect would be that the clients would communicate with each other (like some kind of variation of client side prediction), and either send their commands directly to the server, or to the host which sends to the server. The latter obviously again requires
absolute trust in the host to send the right commands (you don't want the host server telling the main server that you went all in with 2 7 off, do you?). If the clients communicate directly to the server and let the server "overrule" the prediction, then the only point of the P2P is for potentially better time for the client response interaction instead of waiting for the server to receive the info and send back out the next gamestate to all clients. Even with this method, it requires the clients to allow communication to other clients through sockets, most likely requiring port forwarding (security risk).
In any case, there must always be a server at least from my perspective. Maybe for a "home game" (over the internet...) where you absolutely trust each other there may be a possibility for this, but not for a casino type situation or playing with random people.
There's a general rule with game programming: trust the client as little as possible. FPS games for instance, trust the client's input, and the rendering is on the client side -- hence, wallhacks, and aimbots/autofire. For poker, this is actually not too bad, since the server dictates the actions the client can make, and if it receives the client trying to do something that's not possible, it simply ignores it. Cheating at the client level is much harder as the client is essentially bound to do only a set number of things that cannot be made any better artificially. That's why I think the only successful cheats in online poker have been people working together or people who have access (whether legitimate or hacked) to the administration area. If you take away the server protection of all of this, you just open the doors for rampant cheating for the more technically savvy.
Regarding 2+2, I certainly may consider posting there once I have a finished and polished product. This is something I'm doing in my spare time (and I haven't had much the past two weeks), so development time is an unknown variable heavily dependent on life's circumstances.
Thanks for the input, though, and I hope you can understand my concerns over P2P. Maybe it would be possible to implement this in a similar fashion to how bitcoin prevents stealing (
https://en.bitcoin.it/wiki/Introduction), which may be something to investigate at down the line.
Edit: For clarity, the reason I say "down the line" is because we'd need a significant amount of people running this hypothetical poker system to prevent cheating. Even then, I'd have a lot of concerns about how much time it takes to verify even a drawing from the deck, much less verifying actions (not sure about how necessary action verification is without really thinking about it)... Maybe someone else more familiar with this kind of distributed system programming could chime in, as I'm more a functionality logic programmer (games, business applications, etc).
