Bitcoin Forum

I'm going to write some poker software and then probably expand it to general gambling with bitcoins, and I had some general questions which you don't have to be a programmer to answer.  I write in a number of languages, and I'm trying to determine which one I should use. 

PHP/AJAX would be for absolute ease and fast development, while not necessarily being efficient (or arguable robust) which may become a concern if a considerably large amount of people start playing there.  Also, my basic tests so far on local ajax client->server->clients type of events is not that great; it's fairly quick, but not particularly great.

C or C++ would be for speed, both on the server end and the client end.  Everything would be over UDP.  I think it is possible to put http over UDP, and there are probably already some examples or something of that nature that outline this; still, I think if I went that route, I might as well do it in C/C++.  The only reason I have against using native binaries is that it requires installation or at least running of the binary on the system, whereas PHP requires no download -- there is something to be said about ease of use to the end-user.

Last one on my list of candidates is Java (I'd probably write the server in C/C++, though).  I personally am not an advocate of java, but only having to load an applet seems simpler.

If I follow the large poker site's examples, I should just write it as a program and have the user download.  This is where I'm leaning.

Aside from the question of language, I have a question regarding transactions.  I've read somewhere on these forums at one point that I should be 1) backing up the wallet on every transaction (and storing the backups in multiple locations of course), and 2) generate a new wallet for each transaction (not sure if that's correct).  What are your thoughts on this?

Regarding initial deposits, I know it's in the wiki that there could be some sort of escrow service that could allow the user to instantly be credited; lacking that, should I just make the user wait until it's been validated by X keys (excuse me if I am not using the proper bitcoin-centered terminology)?

Thanks for the input.

Back up the wallet every so often. And you probably mean generate a new address for each transaction. Although I'm sure you could just make a unique address for each player then you can keep track of money put in by each player.

I haven't been making millions off the industry like those large poker sites, but my gut tells me that potential customers would be more willing to try a no-download version, e.g. an in-browser java, html5, or flash setup.  Especially since bitcoin users are less willing to download exe files than the common PC user.

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

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

I would prefer AJAX.

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.

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.

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

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 :(

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.

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.

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.

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. 

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

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

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.

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.

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... ;D

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

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

right now its only enabled in chrome and safari afaik


that sounds like a plan.

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.

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

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.