[heartbeats]

> What would be sort of awesome, though, would be a distributed bank (or prediction market, or casino) along these lines

I think this is already possible for poker, and will never be possible for prediction markets.

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

[noduerme]

Given a pair of hole cards and a hash from a server for everything else, you can do this. But a fair poker hand is dealt from a truly randomized deck. Some central server needs to be the arbiter of randomness (not to mention being the actual escrow service for the money in the pot -- which is the other service provided by prediction markets besides deciding how to resolve bets). Those things - randomness, arbitration and escrow - still can't be completely devolved to client-side processing, or at least not without recourse to ludicrous hacks like public ledgers (aka blockchains) which still run the risk of 51% attacks.

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.

[heartbeats]

> Some central server needs to be the arbiter of randomness

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.