No server – no problem

How a Decentralized Poker Protocol serves poker with no Servers

How cPoker creates an environment that removes the need for players to trust a central server to honestly administer a game

The traditional model of a poker application system starts with a server holding the entire state of the game. It holds the deck order and deals cards to each player, and it accepts and remembers their bets. The pot, shuffling, and the payout only happen if the server and therefore the provider allow it. On the surface, you might think the server only has a strong incentive to play fairly – but when we consider more deeply the ways that a server might misbehave in subtle ways, it becomes clear that strong financial incentives exist, revealing an essential conflict of interest between a central server and its p(l)aying audience.

cPoker resolves this conflict of interest, by putting the shuffling directly into (partial) control of every player that has a stake in the game, and by preventing ANY non-playing party from influencing the shuffle in any way. It also supports impartial witnesses, who act like a proctor supervising a class, serving players with this oversight role, that also provides additional guards for safety during the final pot-distribution stage of each game.

The cPoker protocol, built on fundamental academic research in cryptographic techniques for verifiably-secure poker, provides a paradigm shift that removes the need for poker players to trust ANY server with the fairness of the game and, in particular, of the shuffle.

The cPoker protocol creates an environment enabling implicit trust, by involving every player in the mathematics of the game

How does the poker protocol create an environment of implicit trust? First, cPoker requires only the players of the game to participate. It also depends on the presence of a shared communication channel, and a set of messages that the players exchange amongst themselves using that channel, in interactions describe more below.

Who deals?

The protocol starts with the selection of any player to be the “dealer”, using any shared convention – at a traditional physical Hold’em poker table, a “dealer button” is passed between players, and we can use this same convention for choosing the dealer in cPoker. cPoker needs at least 3 players, but can easily support 6 or more – using the same semantics as a physical game of Hold’em.

So the protocol starts with the dealer, whose software-agent (the program they run on their computer) chooses random numbers, to order the cards in a first-round shuffle. The dealer passes a representation of that shuffled deck to the next player, by sending a message through the players’ shared communication channel – the message contains the deck-representation, and a flag indicating its message-type (“partial shuffle”).

Every player shuffles their received representation of the deck, contributes their randomness to the deck. Spoiler: they also add encryption to the representation, to guarantee card secrecy.

Creating My Own Guarantee

I’ll shuffle those cards too, please and thank you very much

The second (and each remaining) player receives the partially-shuffled deck, does another shuffling action on that deck, and passes the resulting deck representation from player to player until everyone has had a chance to prove for themselves their own ability to trust the randomness of the deck order. Their re-encryption of the cards gives them assurance of card secrecy.

Having conducted a series of partial-shuffles, and having come to a N-way shared agreement between N players that there is a final representation of the fully shuffled deck – a representation that every player has had the opportunity to ensure is BOTH random AND secret … the game can continue.

The Little Reveal

The deck representation uses a clever encryption algorithm, which changes the visible representation of every card – so the message containing a player’s re-shuffled deck has nothing in common with the partially-shuffled deck they received. Mind-blowing, right? But stay with me – we’re about to reveal every player’s hole cards, and it’s almost like a magic trick in its simplicity and beautiful elegance.

Consensual reveal of community-cards and hole-cards is done by gradually reversing the effects of the partial-encryptions done on the deck during the shuffling phase of the game.
** the actual mathematics work a little differently in the form they take, but this description can give you a strong intuition.

Imagine a 4-player game: four players (actually their local software) modified the deck, **adding their cryptographic signal** to every unique card. Let’s start by revealing the hole-cards of player 4, in 4 simple steps (these two hole cards are private to each player – no peeking!)

everyone contributes a partial decrypt to player 4, who combines the partials to see the card values

Player 1 takes the shared representation of Card 4 and card 8, and modifies their representation by **removing their cryptographic signal** from each one and creating a **partial decrypt**.
Player 2 does the exact same thing, **removing their cryptographic signal** from two cards. This **partial decrypt** or **partial** is useless, unless it’s combined with the partial from all 4 players.
Player 3 follows suit, and each player 1-3 sends their **partials** #4 and #8 to each other. Only player 4 really needs these, but it’s safe to simply share them with everybody since Player 4 keeps his own partial to himself to keep the cards private.
Player 4 makes their own **partial** too (and doesn’t share it with anyone). Then, through the power of mathematics as applied to very (very very very) large numbers, these 4 partials are combined in a way that reveals the original (“2 of Hearts” and “Ace of Spades”) values of cards #4 and #8.

In these steps, all 4 players are running the same mathematical operations to partially-decrypt each of the 8 hole cards dealt to the 4 players. And each of the 4 players runs the same Step 4 to combine 4 partials to view their own hole cards. Result: private hole cards, that everyone can trust.

Is it just a magic trick?

For the rest of the game, betting predominates the message protocol (message type=”bet”, “raise”, “check”, or “fold”). (Side note: the protocol keeps a short-term record of all these messages, for integrity-checking purposes at the end of the round).

But in between betting rounds, the community cards are gradually revealed. The same 4-step process from above is used here, except that all 4 players share their **partials** with each other, for cards #9, #10, #11 (“the flop”), #12 (“the turn”) and #13 (“the river”). And all 4 players run the step 4 combine activity, showing the resulting community cards onscreen.

Wow, it really does seem almost magical. “HOW DOES THE TRICK WORK?“, we hear you cry. For those of you (hi!) who are not cryptographic experts, we can quickly provide a pretty strong intuitive understanding of how the decryption works. Consider these facts:

You know that 3 * 7 * 5 is 105
It wouldn’t take you long to recognize that 105 can be deconstructed to a 3, a 7 and a 5, multiplied together.
… but what about 23 * 57 * 271, and 355281? That’s a much harder number to deconstruct, and will take you a lot more time.
What about 6233? Hey, that’s a much smaller number than 355281. Still pretty hard to deconstruct, though. (it’s 355281 / 57, and analogous to player 1’s **partial**.
And 15477? (its 355281 / 23) – Still hard to deconstruct further. Think of it as Player 2’s **partial**.
Ditto with 355281 / 271, which is 1311.

It turns out that with some clever math using 1311, 6233 and 15477 (you could work it out on paper), 355281 becomes more easily deconstructed – AFTER these **partials** have been shared. The actual mathematics use 3 additional techniques of making the deconstruction problem harder – which is important because, as we know, computers are faster at these maths – but not infinitely faster!

The cryptographic protocols created for cPoker also use much (much, much, much) larger numbers, raising the difficulty of deconstructing our encrypted card representations so far, it might as well be on the moon.

…what about the other 39 cards?

Any cards not dealt to players, and not one of the 5 community cards (that is, cards #14 to #52) are dead to the world, as far as these 4 poker players are concerned. According to the conventions of the protocol, nobody should ever share so much as a single **partial** decrypt of these cards. Furthermore, if even a single player (their software agent, that is) refuses to share a partial for them, they automatically get a mathematical assurance that nobody else can peek at the remaining deck.

The amanuensis, or record-keeping

Wait, waait, there’s more! The cryptographic protocol for cPoker also keeps an integrity-checked record of the entire game. But perhaps that’s better left as a topic for a different article.

Still, it’s worth mentioning that a gauge of a decentralized poker protocol’s fairness can be enhanced, but never compromised, by adding game witnesses that attest to the the final result, having observed the messages that the player’s software agents exchanged during the game. These witnesses, serving in an oversight role, could potentially flag conspicuous behaviour and trigger additional investigation by the other players to verify and resolve any potential problems.
So yeah, there’s that too.