To get the discussion moving, here are some proposed solutions to these problems - I'm purposefully leaving out technical details so as not to cloud the issues too much.
* Shuffleing the deck - I assume this is solved problem.
* Agreeing on the game state given the imperfect view of the full state that each player has
Each player has to agree that their window into the given state of the game is valid. They can't see other players cards, but they know how many cards have been dealt and what cards they have.
* Handling the pot in a trustless manor
Each player has a key which they use to generate a M of N address to hold the pot money, which they must deposit in advance. Once the winner of the game has been decided players must reveal their key in order to release the funds. Read the next point if this seems stupid.
* Handle players dropping out
To deal with the problem of players dropping out of the game, keeping their key and therefore preventing the winner of the game being awarded the pot, players must deposit the buy in amount X 1.5 (or some other arbitrary number) when buying into the game. When the game is over, the 0.5 X buy in amount will be released to each player providing that all keys have been submitted.
So the winner gets the pot and players are incentivised to be honest, or risk losing money.
* Agreeing who's go it is - I assume this is a solved problem
* Incentive to mine the blockchain
All the events which take place in this model of decentralised poker are transactions of a particular type:
Game created,
Player joins,
Cards shuffled,
Player bets/folds,
Next turn,
etc,
This means that the every step of every game is recorded inside the blockchain for this DAC. Mining the blockchain for the DAC is important of course, and to incentivise this activity miners should receive some proportion of transaction fees (or cut of some other fee associated with the system), in a POS style arrangement.
* Agreeing that a given game in progress is valid without knowing the state
In order to mine the blockchain, miners must be able to validate a game in progress, but they must not be able to see the full state of the game for obvious reasons. This is an interesting problem - I'm thinking that you could probably solve this by hashing the state in some way and then having the secret be revealed when each game is ended, thereby allowing the game to be verified in it's hashed state during play, and then verified as a valid game when the secret is released at the end.
* Confirmation times
Short block times will be needed for sure and it might even be necessary to do a lot of the work using 0 confirmation transactions.
* Collusion
This is a popular point of contention in decentralised poker. The problem exists in regular online poker as well - the only difference in the significance of the problem is that payouts are prevented if collusion is detected by the centralised poker host, whereas in decentralised poker this is probably impossible.
The best you can hope to do is to reduce the probability of collusion. For example, you could enforce a rule that each player at a table must be on a separate IP address. The DAC could confirm this and not allow two players under the same IP to join. Of course, these is nothing to stop someone from having each player run a separate virtual machine in different parts of the world. But that is much harder to do than to simply fire up two clients on one machine.
If you wanted to add some analytics to help with the collusion problem, you could analyse the paying habits of individual players by looking at the blockchain - if you find that there is an unusual clustering of particular players staying together on tables, you could flag this as a fact inside the client and let the player decide to join any future games with these players. Of course, colluders would attempt to circumvent this by creating new accounts regularly, in order to minimise the problem with this, you could enforce a maximum bet size for new players, or at least just telegraph this information to players joining a game, to let them decide.
* Bots
You could enforce a rule that each player at the table must complete a CAPTCHA at regular points during the game. Ugly, but effective at preventing bots. Combined with the IP collusion rule, this makes it much harder for bots to profit in this system.
Ok, I'm waiting to be shot down on these ideas, so please fire away!
Cheers, Paul.