Interesting. I had given up on that idea. Not just for poker, but MMOs n stuff. Figured anything of importance had to run server-side.
Prediction markets require human resolution of "fuzzy" questions. For example, who won the 2020 US presidential election? You can see why the limiting factor isn't the machine.
But for poker, why do you need FHE? To play poker, you have to deal two hole cards and five community cards. First each player gets two secret ("hole") cards, then three community cards are dealt ("flop"), then potentially another ("turn"), then potentially another ("river"). This could be done programmatically as such:
1. Each player generates five secrets: k_HOLE, HOLE, FLOP, TURN, RIVER
2. Each player derives public key K_HOLE from k_HOLE.
3. Each player publishes the hash of each secret in addition to K_HOLE.
4. Each player publishes their value of HOLE, which is checked against the hash from previous step.
5. To get the two hole cards for you, calculate H(HOLE_1 || HOLE_2 || ... || HOLE_N), decrypt the resulting value using k_HOLE (secret to you), then deterministically turn this into cards (for example: hash it, then map the first half into 52 values and the second half into 51 values)
6. Once it's time for the flop, all players publish FLOP. Then calculate H(FLOP_1 || FLOP_2 || ... || FLOP_N).
7. Repeat for turn and river as necessary.
The only difficult part is how to handle colors, but I don't think this is a serious issue, since nobody counts cards in poker anyway. (We can trivially ensure flop, turn and river don't repeat cards, so it's just a question for the hole cards vis-a-vis the community cards)
EDIT: Looks like someone has already tried to do this seven years ago: https://github.com/zweicoder/PokerPhase
Encrypt the whole VM and all i/o on each client though, so that the machine state itself is encrypted at all times, and you can trust their generation of the hole cards (as far as you can trust a PRNG).
Under this new paradigm, though, the power over the systems probably goes to some new certificate authority that doubles as a routing (signaling) service.
What, no? My hash-based system is entirely random. The only issue is that draws are done with replacement, so two players may both have e.g. six of spades in their hand. This is aesthetically unappealing, but doesn't alter the actual maths of the game. (There are more complex solutions to this, however)
> not to mention being the actual escrow service for the money in the pot
FHE doesn't solve this, since FHE can't actually interface with your bank. Even if it could, I could just log in on my phone or physically walk into a bank branch to freeze my account before I have to pay out, so you still need a solution for the money layer.
> you can trust their generation of the hole cards
You can do trustless generation of hole cards already, as described in my post.
What would be sort of awesome, though, would be a distributed bank (or prediction market, or casino) along these lines. If every node can donate processing power to run totally encrypted transactions, it's a game changer. You could finally rely on client-side processing to deal poker hands and process game states without a central server, for example.