|
|
|
|
|
by noduerme
1219 days ago
|
|
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. |
|
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.