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.

Hi all,

I wanted to start this thread just to thrash out the problems in solving decentralised, trustless poker. I'm taking a lot of info from this thread https://bitcointalk.org/index.php?topic=362901.0 by W-M on bitcointalk.

Specific to decentralised poker:

• Shuffling the deck
• Agreeing on the game state given the imperfect view of the full state that each player has
• Handling the pot in a trustless manor
• Handling players dropping out
• Agreeing to who's go it is

Specific to blockchain based, decentralised poker:

• Incentive to mine the blockchain
• Agreeing that a given game in progress is valid without knowing the state
• Confirmation times

Problems with online poker in general:

• Collusion - ensuring each human at the table is unique
• Bots - subcategory of collision, since poker AI is poor unless they collude.

Love to hear if you have any more?

Cheers, Paul.

For smartphones, iOS 7.0+ and android 4.0+ already have features required to implement mesh networking in you apps, and that's one of the reasons why apps like firechat are so popular these days.

I don't think firechat uses Mesh protocol - it might be some other technique like ad-hoc?

Have you considered the technical issues at hand with this idea?

Most existing wifi routers would need a firmware flash to support the correct mode on the NIC. I'm pretty such most mobile phone do not support this either by default.

There are a lot of forex brokers providing price feeds for metatrader. Has anyone considered a solution using those feeds?

Ok, back in devils advocate mode.

There is no way I'm giving my mobile phone number away just to receive a small amount of BTSX.

The industry's solution to proof of person is the solution to a google captcha. No personal information required. How is this better?

Everything I said was applicable. Excuse my tone in the last post, but I am annoyed that all of my ideas being ignored or immediately shut down without any discussion... this is just the latest example. (https://bitsharestalk.org/index.php?topic=9876.0)

Whereas registered companies can be sued/jailed and victims can sometimes be recompensated with success, decentralized companies can trim the fat and provide a cheaper service. It is a give and take situation.. some people will prefer to pay much higher fees with the "security" a known company provides and some will be willing to take a risk and save money by using a cheaper service. It comes down to how risk adverse or risk prone someone is.

There is a big difference between trustless and trusted, as you know. These things are binary opposites. What you're proposing is a middle ground solution which will be more vulnerable to exploitation than the established method of handling trust. Yes, DPOS is this system, but the asking delegates to produce blocks and asking them to handle critically sensitive decisions and processes using their own judgement are two different things.

I just don't see the benefits you list are worth the inherent risk, especially in a nascent and delicate ecosystem which aims to gain acceptance from the outside world.

It would be the same as trusting a company to perform a centralized service, except that you trust the delegates (whom you can vote out) and most of the fat is trimmed and thus a DAC can most likely perform the service for much cheaper than a centralized counterpart.

But an anonymous entity has zero risk associated with performing a scam and stealing from it's users. A registered company has a lot of risk associated with the same action, which is the entire point of having a company in the first place.

All the artificial trust mechanisms that might ever be possible to put in place to instill trust in an anonymous entity would be able to make such an entity less trustworthy than a registered company at best, simply because there is no legal recourse available.