Bitcoin Forum
December 10, 2016, 06:57:47 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Poker/Casino Programming  (Read 19020 times)
luv2drnkbr
Hero Member
*****
Offline Offline

Activity: 771



View Profile
April 20, 2011, 02:34:25 PM
 #21

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.

1481396267
Hero Member
*
Offline Offline

Posts: 1481396267

View Profile Personal Message (Offline)

Ignore
1481396267
Reply with quote  #2

1481396267
Report to moderator
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481396267
Hero Member
*
Offline Offline

Posts: 1481396267

View Profile Personal Message (Offline)

Ignore
1481396267
Reply with quote  #2

1481396267
Report to moderator
1481396267
Hero Member
*
Offline Offline

Posts: 1481396267

View Profile Personal Message (Offline)

Ignore
1481396267
Reply with quote  #2

1481396267
Report to moderator
1481396267
Hero Member
*
Offline Offline

Posts: 1481396267

View Profile Personal Message (Offline)

Ignore
1481396267
Reply with quote  #2

1481396267
Report to moderator
kalfu
Newbie
*
Offline Offline

Activity: 13


View Profile
April 20, 2011, 07:00:02 PM
 #22

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).
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
April 20, 2011, 09:52:11 PM
 #23

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.

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.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!