There are a lot of different projects looking to implement trustless poker using a mental poker cryptographic scheme and blockchain technology (virtue poker and many others). But most of these projects are not ready for use. They are usually trying to emulate an entire gambling site which is a big undertaking.

I thought perhaps in the meantime we could try to simplify the problem a little and provide a dApp which is solely a heads up (two player) holdem cash game that is provably fair and whose buy ins and payouts are secured by smart contract. With only two parties, many of the subtle complications like player dropout become simplified. The idea is for the two parties to (1) pay their buy ins into a contract; (2) engage in a p2p poker session logging proofs of their game state; (3) present a proof of game state to the contract to receive the payouts.

I am already actively developing a heads up, texas holdem, p2p protocol (secure mental poker with proofs). But could (1) and (3) be feasibly built around such a protocol on ethereum? Could we write a contract in solidity that simply knows how to: take in funds from 2 parties, evaluate game state proofs, and remit funds. If the actual playing of the game can happen off chain, then something like this could already be usable (no lag during game play for blocks to be processed). Glaring difficulties? Misconceptions or false assumptions? Size or complexity limitations on the proof of game state data that must be evaluated by the contract?

  • 1
    Sounds exactly like State Channels, so yes it's very doable – Lauri Peltonen Oct 28 '19 at 13:52
  • @LauriPeltonen Yes now that I'm reading about state channels, this is just what I was describing without knowing what it was... thanks for pointing me there – cypherpleb Oct 29 '19 at 21:18

As you mentioned it's a big undertaking to implement something big on any platform, take alone Ethereum. Ethereum is not very well suited for big and complicated projects especially if they require data storage. Mostly due to difficulties in upkeeping the code and making it bug-free.

The scenario you are describing is exactly what State Channels are meant for. State Channels allow for doing transactions off-chain between participants and only recording the start and end data to blockchain. The blockchain also guarantees a fallback so no party can fall victim of disappeared or malicious participants.

With State Channels you don't need to really worry about how complicated computations are or how much data is needed to reach the next transaction. The blockchain only needs a fraction of this information so the whole scheme is cheap.

A variation of sorts to State Channels is Plasma. It's similar but requires a real (sub)chain. It's therefore slightly more complicated but more flexible.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.