Topic: Poker/Casino Programming (Read 19587 times)

I haven't read the rest of the thread, but I agree that one address per user is good. That way all they have to do is send some Bitcoin to the address they already have on file.

As far as backups, the getinfo() JSON-RPC method returns a field called KeypoolOldest. This is the unix timestamp of the oldest key in the key pool (unused keys). You only need to create a new backup when your newest backup is older than the oldest key in the pool.

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).

Dear GOD please post this here:

http://forumserver.twoplustwo.com/45/software/idea-relating-new-regulation-decentralized-poker-software-1021113/

I am trying to generate interest for this type of thing, but it's rough going!  Also, since you were asking for input, please consider not having a server and making it peer-to-peer.  For me personally, one of the big goals of a project like this is having it be impossible to shut down.

right now its only enabled in chrome and safari afaik


that sounds like a plan.

I guess that's some kind of joke?  Hard to determine the difference between sarcasm and sincerity in text.  If there's a serious question in there, I guess just let me know...

By your confused words i can see that you, even being a programmer, know less about php than I do...  
Choose another language! It's for the best...

But yes, you are right, no php/ajax for desktop clients. Use it for the website only, if you can't find something better, ofcourse

PHP is server side scripting.  CLI (command line interface) is just the ability to run it from the command line.  You could use this to run a console client, but again it falls on having the user install software (they at least need the php client) + run the script on their local machine.  If I choose to encrypt the client code, then they'd have to trust me.

PHP CLI is mostly just for running offline scripts (like perl or bash).  Most people use the PHP apache module.  I'd be running the PHP-FPM and fastcgi on nginx.

Also, I doubt most people would have any interest in playing with a command line poker client.

Yes, i understood you, but i think that for what you are looking for you should use php-cli instead of cgi because cli mode doesn't create so much overhead with http headers, etc...

Sorry if you misunderstood what i meant to say. I'm no expert in this, in fact i'm not even a programmer, I'm just a curious guy, nothing more.

No, I was referring to http://www.php.net/manual/en/function.socket-create.php. 

are you talking about php-cli? http://www.php-cli.com/php-cli-cgi.shtml

The only most recent version of major browsers that doesn't have Web Sockets is IE9.  I'm pretty sure all other major browsers have support (although I think some need it enabled first).

I most likely will write the server code in C or C++ and have the first version of the client in PHP/Ajax but have the script connect via the PHP socket code.  This way, it'll be easier to add a C++ client down the line as optional for a better experience. 

This is pretty bad logic. People are going to want to try the software before they trust and pay you anything and even then they will start small. There are lots of sites I'd send 5BTC to, but not install their software.

I'm not saying trust can't be built, but it's a process and at least a little harder to get people to download.

use websockets and hope that they will be activated in the major browsers soon?

edit: i think trusting the binary is a non-issue with c/c++. the user already trusts you enough to give you some bitcoin. so its very likely that he also trusts you enough not to spread malware.

It seems that the only secure way to do it is with js talking to a java applet: http://sly.w3m.hu/socketjs.  There is a way to do this with flash, but the method seems insecure on the server side; plus, I hate flash and want it to die, which hopefully will happen when HTML5 is widespread.

I understand your point, but I disagree that I'd have to make UDP do all the same things TCP does.  It's easier to send duplicate packets (use more bandwidth without increasing latency) and handle it at the server end.  We're also talking about very small amounts of data.  The client will need very little information to be sent.  I should have mentioned that the deposit and withdraw functionality will be handled in a php website, so we're only talking about basic commands: bet, check, etc + game state updates.  Even with 10 duplicate packets for every packet, the consumed bandwidth would still be minute.  I suppose the problem with that would be for people using tor or jap that have greatly reduced bandwidth and have to get the packets intact through that.

The php sockets idea is a dead-end, since the php socket code/client would have to be run on the user's machine (I doubt people would want to have to install a webserver to run the php).  Of course that would mean the code would have to be open to again address the concern of executing code on the client's machine.  I have not found any method (currently) to do sockets from the client side.  WebSockets (used to be part of HTML5 specs) is something that will eventually be available which can keep a connection between the client and the server; that would need to be finalised and supported by the browsers first, though.

Regardless, I've already decided to do the code in PHP and AJAX.  It's easy, it doesn't require people to do anything except visit the site (with JS enabled, though), and it's probably fast enough.  As you rightly pointed out, the main issue with speed is not the fact that it is TCP but that each action using PHP/Ajax would be a new HTTP request.  Since browsers are built around TCP, perhaps there's a way to use a single TCP connection.  My main concern was the "turn time" or whatever you want to call it and the fluidity of the gaming experience.


I did see that post, and I wouldn't put it past them, but I would hope that because it's in a bitcoins that it would be grey enough that they'd tie themselves in red tape.  However, I suppose it's more likely they'd "act first" and then tie me up in red tape

...then you'll have your domain seized by the FBI.

http://www.internet-poker.co.uk/Poker-News/Poker-Sites/PokerStars-Site-Shut-Down-by-FBI~4109.html

Why would you use UDP? It's not going to give you any speed improvements if you're just going to replicate the reliability/stream functionality (which you'll probably need to do). You just need to have all actions go over a single TCP stream so you don't have to keep opening new connections. I don't know if you can do this with Javascript.

PHP can use raw sockets, so you can do anything with it. I wrote a basic Bitcoin network client in PHP.

Well, you learn something new everyday.  PHP does have some UDP functionality, although because it's a server side scripting language, I'd still have to figure out a way to have the client's requests not go through the standard http overhead.  I'll figure it out.  malditonuke's response answers my question enough that I know which direction I should probably go in.

I hate Java applets. They freeze my browser for a few seconds and screw up the page.

I would prefer AJAX.

Wallets are small enough that I might as well back them up every transaction, but I do like the idea of just using one address per user.


That's my main concern with a binary.  I suppose I could open source it to quell the doubt, but my concern with that is having someone decide to find any flaws in the software (probably will encounter this with it closed, but it's at least not as easy).  My motto on code security is that it is only possible with 0 lines or infinite lines of code (i.e. every possibility possible).

Java may be the best route to go for client speed and ease on the end-user (it does require people to DL java, and personally if a site requires java, I typically just leave).