General Procedures and Flow of Decentralized Poker

by **BluMnkyHugr** Thu May 22, 2014 12:01 am

Creating a networking

“.....we have designed a decentralized protocol, called GameCast, that enables users to play turn based multi-player board games over a peer-to-peer network”

“The GameCast protocol supports three processes, dissemination of peer and game information within the network, game agreement, which allows one peer to invite another by sending invites, and game-play, which enables peers to play a game over the network.”

Our current GameCast implementation, called TriblerG, is built as an extension to the Tribler ﬁle-sharing application, and focuses on enabling users to play online chess through the Tribler-G GUI.

GameCast is effective. Based on the observations made during the emulation, an
opponent on the network can typically be found in a matter of seconds.

GameCast is scalable

Gamecast can be thought of as a place holder for a possible working model of a peer-to-peer network built for the specific purpose of text based turn based multiplayer games. Although it was developed for chess it was created with all games that fit the formerly said requirements. It was meant for the decentralization of games, including poker, however it has 9 problems we will visit further in this paper.

Creating a game

The idea of gamecast is that a 'trusted' player starts up a game and send an invitation with certain parameters to the network. Players respond to the invitation through the network and connect in this manner. The problem here is allegedly picking a trust-able person to start the game and that this person will essentially act as the dealer or even pit boss. But their job is mostly only in terms of creating the game, accepting enough trusted players (vs non trusted) and starting the game.

Player's escrow

Players escrow their money, which can be confirmed by the player that created the game. The problem here is having trust-able escrows which can be determined by the player that created the game as well (with the assumption they are trust worthy.

Game play

We describe a simple gambling game in which n participants each put down a fixed amount of money and one of them, selected at random, wins and takes it all. We describe how this game can be operated in cyberspace, without knowing anything about the other participants except for the bit strings they transmit. We show how the genuine winner can convert the bit strings back into t money, without any other gambler or eavesdropper being able to do so before her. We also show that it is possible to have confidence in the fair running of the game even if all the other participants, including the deal, are crooked and are prepared to manipulate the protocol to their advantage.

The game portion of cyberdice, excluding the crucial payment issues, is the multiparty computation of a random number, clearly connected to the widely studied problem of distributed coinflipping.

Players agree before hand to use the same verifiable rules and game flow protocol. We can expect this is addressed in the decentralization of Chess and is certainly mathematical possible (and practical). And poker fits the requirements to adapt the current model to suit its game play.

Players have different deck and shuffling protocols at their disposal and should expect no significant changes in the dealing procedure.

The cyberdice solution has 4 main problems however it's solution is built on the backbone of the players using an escrow which is a perfect fit for this model.

Payouts

Escrows are paid out automatically based on results. Neither decentralized chess nor cyberdice have issues with reporting false results to an escrow. However we will outline a solution for this anyways, as well a possible system for players to back check that proper payouts were distributed to proper players based on proper results.