E.Poker, as a solution to D.

Poker
The problem of decentralized poker has been discussed for over 5 years. Developers seem to have
great difficulties solving the problem, perhaps because they are looking at it from the wrong
perspective (capitalistic), or perhaps they are waiting for a certain technology. elow is one
possible model for decentralized poker, based on !Tribler"#$% Decentralized &ocial 'etwork for
(laying )hess *nline+ in con,unction with !)yberdice$ peer"to"peer gambling in the presence of
cheater+. (layers will use an -
rd
party escrow service to e.change currency for a right to chips or a
tournament seat. y outlining the general process we are able to outline all the remaining
problems of the separate processes, and we are able to look at which problems are naturally solved
by their combination. %fter e.hausting these observations we look at a solution that involves a
coming technology the the players should work with in tandem with their community (forum /.0).
General Procedures and Flow of Decentralized Poker
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 o peer and game inormation
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.
!ur current GameCast implementation, called TriblerG, is built as an e"tension to the Tribler #le-
sharing application, and ocuses on enabling users to play online chess through the Tribler-G G$%.
GameCast is eective. &ased on the observations made during the emulation, an
opponent on the network can typically be ound in a matter o seconds.
GameCast is scalable
#amecast 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 te.t based turn based multiplayer games. %lthough it was
developed for chess it was created with all games that fit the formerly said re1uirements. 2t was
meant for the decentralization of games, including poker, however it has 3 problems we will visit
further in this paper.
Creating a game
The idea of gamecast is that a 4trusted4 player starts up a game and sends an invitation with certain
parameters to the network. (layers 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. ut their ,ob is mostly only in terms
of creating the game, accepting enough trusted players (vs non trusted) and starting the game.
Player's escrow
(layers 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
'e describe a simple gambling game in which n participants each put down a i"ed amount o
money and one o them, selected at random, wins and takes it all. 'e describe how this game can
be operated in cyberspace, without knowing anything about the other participants e"cept or the
bit strings they transmit. 'e 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 beore her. 'e also show
that it is possible to have conidence in the air running o the game even i all the other
participants, including the deal, are crooked and are prepared to manipulate the protocol to their
advantage.
The game portion o cyberdice, e"cluding the crucial payment issues, is the multiparty computation
o a random number, clearly connected to the widely studied problem o distributed coinlipping.
(layers agree before hand to use the same verifiable rules and game flow protocol. 5e can e.pect
this is addressed in the decentralization of )hess and is certainly mathematical possible (and
practical). %nd poker fits the re1uirements to adapt the current model to suit its game play.
(layers have different deck and shuffling protocols at their disposal and should e.pect no
significant changes in the dealing procedure.
The cyberdice solution has 6 main problems however it4s solution is built on the backbone of the
players using an escrow which is a perfect fit for this model.
Payouts
7scrows are paid out automatically based on results. 'either decentralized chess nor cyberdice
have issues with reporting false results to an escrow. 8owever 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.
Outlined prolems and natural solutions
There are many ways to approach and view this problem, and many ways to set up decentralized
poker. 8ere we pick a solution that is tangible and understandable, scalable solvable and
implementable in a reasonable and practical manner. &o far we have left many holes in the model
and we should start by looking at the problems referred to in the above, and check for any natural
solutions that arise. 5e hope the remaining problems outline a holistic solution that players can
view as a wrapped package.
!ssues from t"e Decentralization of c"ess#
D.)hess categorizes their issues into / groups$ improvements that 9. e.isting technical issues, and
improvements that somehow e.tend the system.
!mpro$ements t"at %& e&isting tec"nical issues
%mproving the synchronization mechanism
'hen playing a game, each player keeps track o how much time each o the players has used so
ar. (owever, the time that passes between the moment at which a player makes a move and the
moment the other player)s* receive a move, will result in an oset between the clocks o the
players. The +%C, deals with these network latency issues by introducing Timeseal, an application
that runs on the player-s machine and noti#es the +%C, o the time that the player has taken to
make a move. The GameCast time synchronization mechanism closely resembles Timeseal, in that
both mechanisms measure that time a move has taken rom the player-s perspective. $nortunately,
since a player is on a trusted entity, this mechanism also introduces a vulnerability which is likely
to be e"ploited by malicious users. Thereore, we would like to alter our current mechanism so that
it would be more tamper proo.
5e might solve this with a single trusted player (dealer:game maker), and have them be the central
authority. 5e will revisit this in the conclusion.
%mproving GameCastsecurity
.n issue with GameCast, and peer-to-peer networks in general, is what happens when one or
more malicious peers are introduced into the network. +or instance, malicious peers could start
distributing ake game inormation in order to aect the rating o a player )i.e, ,ybil attacks*.
ecause players could escrow from a bitcoin wallet, it can be shown that players account integrity
is safe from players that might claim to be someone they are not. %lthough ratings are different in
poker than chess, this still could be a concern. 5hat players can do to combat this is only count
games that have a certain security and integrity rating. 5e need to understand a new model where
both regs and recs wanted to be trusted and viewed with integrity. &o this really depends on our
ability to 1uantify trustworthy ness and integrity. 5e will address this more in the conclusion.
/ealing with 0.T #rewalls
1any computers connected to the internet today are behind 0.T #rewalls. 0.T creates a private
%2 address realm separate rom the %nternet, which oten results in di#culties accepting incoming
connections rom e"ternal hosts. This results in a number o issues when unconnectable peers are
using GameCast. +or instance, a peer behind a 0.T #rewall receives a random peer invite rom
game buddy, but is unable to respond because that peer is behind a 0.T #rewall and cannot accept
a connection. . possible way o increasing the usability or users that can not accept incoming
connections, could be to increase the role o the super-peers )e.g., messages between peers could
be passed trough a connectable superpeer*.
This seems to be a user friendliness issue, but not doubt will be addressed in the conclusion.
+urther research into protocol parameters
+urther research is re3uired in order to determine what the eects o dierent GameCast
parameters are. +or instance, peers involved in inormation distribution are currently only allowed
to send4receive messages every 5 minutes. (ow would changing this parameter aect the
bandwidth usage6
)urrently this can still seemingly support decentralized poker however we feel we can dissolve this
completely in the conclusion.
Concerning the second group o improvements, which would e"tend Tribler-G, we eel that the
ollowing are among the most important7
8"tending the number o available games
1any people do not know how to play chess or simply do not like it. Thereore,we would like to
e"tend the number o available games to include, or instance, ,crabble, 1onopoly, Checkers, and
Go.
This of course is e.actly what decentralized poker seeks to do.
,upport or random number agreement
'e would like to include a mechanism that allows peers to agree on a random number, which
would help generate random content or games that re3uire this. Think or instance o board games
such as ,crabble and 9ummikub, or card games such as Te"as (oldem 2oker.
This is e.actly what cyberdice addresses, mental poker solves, and there are at least two other
possibly usable solutions in this regard. 2t too is addressed in the conclusion.
2enalize leaving the game beore it is over
Currently, when a game e"pires )i.e., one o the players ails to move in time* it is discarded. This
eectively means that a player who is loosing a game can simply stop playing in order to prevent a
negative impact on his4her rating. Thereore, in uture versions o Tribler-G, the player that ails to
move in time should be considered the loser o the game.
%gain this is an issue cyberdice addresses, and we also can point out is more of a chess problem
than a poker problem since a disconnected player forfeit;s their right to the pot and sometimes their
seat. 2n poker the turn can simply be passed to the ne.t player to act. The conclusion addresses
this further.
8"tending the number o GameCasteatures
Currently GameCast supports the most basic unctionalities in order to allow players to play
games against each other. (owever, there are also a number o additional unctionalities that we
eel would improve the gaming e"perience. These unctionalities include allowing users to observe
a game in progress, allowing opponents to chat while playing a game, support or unrated games
)i.e., games o which the outcome does not aect the ratings o the players*, allowing players to
suspend4resume games,support or game tournaments,support or anti-spam unctionalities or the
discussion board, allowing or the messages in the discussion board to be nested and ordered,
oering chess instruction videos through the Tribler download eature, and introducing some kind
o trust rating or players.
(layers mostly should only be interested in observing games as an invite, rather than being able to
globally search (instant data mining would be available which may or may not be something the
players collectively wish for). ut this writing and its conclusion together show games can be
observable and that global decentralized data can be hidden from data miners (or not) to some
degree. The key change in today4s game (rather than yesterdays) is that global winrate distributions
of legal games will be known, and likely with players specific names (that participate in security
measures). This means players aren4t interested in setting up unrated games as they are not trust"
able (plenty of home game free sites < bitcoin escrow for 4friends4) )hat is supported by the
concluding solution as well as suspending and resuming the game (and negotiating deals for mtts
etc.) %nd the rest it to be taken care of by the community in a manner describe elsewhere.
$ni3ue usernames
:ike the standard Tribler application,Tribler-Gi denti#es peers on the network using 3uasi-uni3ue
permanent identi#ers. 'hile these identi#ers canbe considered uni3ue, the user names are not.
Thereore, it stands to reason that at some point the user will be conronted with multiple players
on the network using the same user name. This can make identiying a certain player di#cult.
Thereore, we would like uture Tribler-G releases to support uni3ue user names, i possible.
(layers can, for e.ample, play from a bitcion wallet address to ensure 4their own4 account security
(while keeping anonymity in this aspect). (layers will set game matching up to favour players that
have the most integrity. Therefore there is great incentive for it. (oker player community can
bridge integrity ratings with other social sites (while somewhat remaining anonymous). The
conclusion will also play a role in this.
Prolems wit" escrow
The only remaining issue in this regard is the trustability of the escrow. )urrently there are open
source -
rd
party trust"able escrows, yet most of this paper relies on the assumption of such and
provided this is possible many of the problem become solved. 8ere we will assume the e.istence
of a trusted escrow and finalize the solution in the conclusion.
Prolems wit" trusting t"e game creator
2t might not be unreasonable in the new model of trusted regs and recs to pick and know certain
trust"able game creators, however this paper will do away with any such need in the conclusion. 2t
still might make sense on many levels to have certain 4known4 players create and monitor games in
some fashion.
Prolems wit" 'andomness and ("uffling security and integrity )gameplay*
%n multi party computer the re3uirement that it be hard to construct a commitment knowing other
players; commitment )but not the values* is known as non-malleability, a term put orward by dole
et al. Combining this with a robustness re3uirement )that players cannot give up in the middle o
the protocol* gives a property called independence. <arious protocols or solving the problem
have been proposed by they re3uire ....messages and ....computation and they assume that only a
proportion )typically at most =4> or =4? o the players are cheating. %n Gennarol;s scheme,
veriiable secret sharing )<,,* is used by each participant to make their commitments. . threshold
scheme is used to veriy )in a zero-knowledge manner* that there is no cheating at this stage. % at
a second, reveal, stage any participant ails to take part then the holder o the shares o their secret
can reconstruct their key and reveal the value the committed to.
5e should e.pect a coming solution in which unfair actions or protocol not in agreement with the
players or the game can be verified in a decentralized fashion. (layers might decide how long this
procedure should remain possible for (if it all, or if not indefinitely). 8owever, it4s very possible in
a trust"able and efficient game that verification in this matter need only to be done in real time. %s
long as this type of 4cheating4 can and will always be caught we can assume very little of these
kinds of actions will happen. The verified software won4t allow players to make these kinds of
plays so it can4t really be 4accidental4. %lso a trusted dealer can help to this effect. )onse1uently
players that break rules or communication protocol will lose their integrity rating ultra fast since its
something that shouldn4t happen.
+aust et al. (ave improved this in <simcast by using Gennaro;s scheme or commitment combined
with 9abin;s idea o backing up secret keys using <,,. The scheme does not re3uire any zero-
knowledge proos and is particularly eicient when multiple rounds occur with the same
participants, because the <,, operation need only be perormed once. The scheme is secure
provided that hal or more o the participants are honest.
(layers could set the games up to only start with half or even more trusted players. 2ncentive is
then more set up for players to want to be 4trusted4 (this could be done in tandem with rake:rake
back systems or class tiers where the cost of playing with not trusted players is 1uantifiable to
some e.tent).
+aust;s scheme is thereore inappropriate or out threat model or cheating players, in that we have
a constantly changing population )so the eiciency o the running multiple rounds is absent* and
because we wish to enable one honest gambler to take part even i everyone else is crooked.
(owever it is much more appropriate or solving the issues we raise in sections ... and .... to enable
us to deal with a small proportion o issuers ailing to live up to their responsibilities.
(oker for the most part does not have a constantly changing population (other than rush:zoom type
games which can, and do, have their own solution). (layers aren4t particularly worried about
sitting with all colluders for other reasons described. The 4issuers4 in this case is addressed in the
conclusion.
'e presented a mechanism to allow gamblers saely to ;put money on the table; in cyberspace,
based on issuers holding money in escrow in e"change or bit strings that can later be redeemed
when certain conditions are met. %nterestingly, issuers oer a legitimate service that is totally
independent o the gambling game.
'e presented a protocol that selects a winner airly )ie randomly* even i all the gamblers and the
dealer are dishonest,and even i all player but one collude against the remaining one.
.l thought this result might at irst appear to e"ceed the theoretical boundaries established in the
literature or secure multiparty computation, in that it reaches a air outcome even i none o the
players is honest, it does so by relying on e"ternal entities, the issuers, whom the player must to
some e"tend trust.
'e have strived to keep the issuers as ar away as possible rom the gambling process and to
ensure that their behaviour can be audited but it is still possible or them to deraud the players
undetectably i they all collude.
The only seemingly real issue then is trust of the issuers.
Conclusion and proposed solution to t"e remaining issues.
+ simple protocol
5e can imagine a simplified understanding of the process that almost works with or without a
dealer. The player to act can send a direct message (much like a skype group) of the decision they
wish to make, while simultaneously posting to a public ledger (much like a forum thread). This
way game flow can run instantly, yet verification can still be done. The verification is done after
the fact on the ledger, but this is okay because each player at the table can collectively verify the
decision and its time frame. %gain the idea is that since cheating will always be caught there is no
incentive to do so.
&o we might have a public ledger and we might choose what goes on it, and what is readable and
what remains anonymous. 5e might decide how longer this public record should be kept and who
might have access to it or when. 2t might even prove to be of great use=
+ new tec"nology
...an 8thereum message can be created either by an e"ternal entity or a contract, there is an
e"plicit option or 8thereum messages to contain data. +inally, the recipient o an 8thereum
message, i it is a contract account, has the option to return a response@ this means that 8thereum
messages also encompass the concept o unctions.
%ll these solutions may somehow fit together to form a solution for the implementation of
decentralized poker however the daunting and truly significant task of development and
programming have not yet been touched. 5e want to now discuss a new technology that renders
this entire pro,ect significantly more simpler than ever though possible. 2t is not intended to get
into the inner workings of ethereum but to e.plain to the players this new technology is the
solution.
A. 2eer-to-peer gambling. .ny number o peer-to-peer gambling protocols, such as +rank ,taBano
and 9ichard Clayton;s Cyberdice, can be implemented on the 8thereum blockchain. The simplest
gambling protocol is actually simply a contract or dierence on the ne"t block hash, and more
advanced protocols can be built up rom there, creating gambling services with near-zero ees that
have no ability to cheat.
5ith ethereum (7) poker works as follows$ 7 can act as a trustable game maker and create
contracts for agreements to play games with certain parameters (the players collectively or even
individually decide). (layers then use 7 to escrow in a perfectly trustable fashion. 7 can act as a
dealer and intermediate hub between all the players and the network. oth with a decentralized
fashion as well as a 4chat4 type feature. 7 can arbitrate game flow as well as write, search, and read
the blockchain. 7 can also be configured for randomness. &o player smay or may not decide to
use the ethereum block chain, and:or may or may not decide to use their own customizable block
chain (likely built with e) and:or another altcoin.
&ince 7 is used for many applications other nodes not poker related can anonymously verify poker
related 4transactions4 with incentive to get the correct answer (and no incentive to give the wrong
answer) in relation to other anonymous and trusted nodes. (layers can pay for this in a sense, but
they can also have many options of optimizing their model to reduce operation costs to ne.t to
nothing.
http$::www.cl.cam.ac.uk:>fms/?:papers:/00@"&ta,ano)la"cyberdice.pdf
https$::github.com:ethereum:wiki:wiki:A57nglishA5D"5hite"(aper
http$::www.pds.ewi.tudelft.nl:fileadmin:pds:homepages:epema:B&c"thesis"ouman.pdf
http$::forumserver.twoplustwo.com:/3:news"views"gossip:ideal"poker"C-5-C0/:
http$::decentralizedpoker.forumotion.org:
http$::www.runitonce.com:chatter:moral"poker"as"a"function"of"integrity: