Topic: Poker and the shared pot at the table in a decentralised network - page 3. (Read 14727 times)

I've given some thought to this and this whole thing starts to get complicated, but it seems to be possible.
(I've now added some clarifications)

Colluding
As for the problem of colluding, it is not inherently a problem of distributed poker, it is a generic problem of all forms of online poker. And Bitpoker could deal with it the same way the centralized websites do: keeping track of how often players play with each other on the same table. (More specifically, it should probably keep track of the number of hands each user has played with other users on the same table.)  This works fine if the number of players will be big enough.

There is one problem though: centralized poker platforms can enforce only one/few accounts per actual user, by requiring a real-world credit card, name, etc. This is obviously not the case with Bitpoker, if it will be anonymous in nature, there should be nothing stopping anyone from creating as many accounts as they want...
Right now I only see one way to do this and still keep everything anonymous: use the economy. It should be economically non-viable for players to create multiple accounts.

Maybe some will consider this "less" anonymous than having hundreds of accounts, or even having a new account for each table, but still, it seems anonymous enough. (A drawback of this is that unfortunately, this would make it easier to analyze each player, i.e., it would be difficult for good players for example to hide the fact that they are good, since all the history is stored in the network.)

A practical thought about how this could be done: to have a fee which will be high in the beginning of the career of each account, and will gradually get smaller and smaller, the more games the player participates in. This, together with some clever randomization of tables that someone else suggested here (for example the system could let each player choose a table only from a very small fraction of existing tables, and only change which tables are "allowed"  once a day or so. This way it would still be possible to have some choice, or get to another table if the existing one has a crazy player, or for some other reason...) should be enough to keep collusion to tolerable levels.

That said, there should probably be a mode of "private tables", so that users that know each other could join the same table, but that is a secondary problem. (Also in that case, there will be no collusion as players already trust each other.)


Now, about who is keeping the money.
When you first think of this, when several inherently hostile players play the same game, there will have to be a third party that will be handling the money, and it will also have to be trusted, because otherwise it could be suspected of colluding with some players, since they all are anonymous.

Except... this problem also comes to mind when you think of normal money, and until bitcoin came, it was the case, but not anymore...

Before in this topic, we were thinking about how to implement this *using* existing bitcoin network, how to have an account in bitcoins and manage funds on it.

But what if... we would implement another blockchain, a dedicated chain for the bitpoker chips?!
In this chain, let's say that along with "normal" addresses, there would be "hand" or "table" addresses, to which all the money is transferred as a hand progresses. And if we could incorporate secure shuffling of the cards into the chain, we could design the network in such way that funds on those "hand" accounts could only be claimed by the winning player, similar to a very complicated transaction script. (This is way too complicated to implement using the current script system of course, so my idea is not to simply start a new chain and use clever scripts, but instead to design a whole new client and protocol.)

(This needs more designing, because there basically must be 3 accounts per player and table, 1 main address, where the player has all his money away from any tables, 1 account of money on that table, and another 1 account of money currently in the pot, and all of those must be managed by the block chain in a verifiable manner.)

Now, as for how to actually deal with the shuffling of cards, this is where I haven't thought it out completely, I see two ways:
1) still use the commutative-encryption approach described in the wikipedia article. Before the hand is started, the shuffled and encrypted deck (or probably it's hash) is publicized in the block chain. Also, some kind of "proof-of-having-a-key" is publicized in the block chain, *for each player*. This can be for example arbitrary known value encrypted with the player's key, so that if you would have the key, you could do the same thing and state that yes, indeed, that is right key for that player. (this will make sense in a moment.)

As the hand progresses, cards are decrypted as required, by passing them around the players. The order of each player's actions is also recorded in the block chain as the hand progresses (let's just say for now there is a reliably way to do this, there is more about this at the end of the post). Finally, as the hand is completed and all cards must be shown to select a winner, the keys of all parties are made public in the block chain. Notice that now, using only information stored in the block chain (the initial deck, ordered decisions of each player, all the keys to decrypt the deck) it is possible to exactly determine the winner. This will be done in the same way transactions are claimed right now in the mainline bitcoin network: collaboratively. You cannot cheat, because it is the network that decides which player has won the money from the hand address. Like in bitcoin, there will be block confirmations, and to generate those, miners will check each win themselves. Think of it as a transaction with a very complicated script that needs a number of conditions to be met for someone to claim the money.

What if at the end of the hand a player has already received all the other keys, and can decrypt the cards, and sees that he has lost, but has not yet made his key available? He could in that case never make his key public, and there would not be any way to tell for sure who has won? This is where "proof-of-having-a-key" comes in. If the network sees that for a given hand, not all keys have been made public, using that proof, it can determine exactly, whose keys HAVE been made public, and thus prove which player did not provide his key. In that case, the money will go back to each individual player, except the one (or the several) that did not provide their keys. Their money is split evenly between the rest of the players, and, since we are making accounts persistent by having a fee anyway, we increase the fee of the player that did not make his key public. This should be enough to discourage anyone from doing this. (Loosing the money + getting higher fee and bad will + not really loosing anything more by just making the key public as the network wants.)

(Just a side note: since we are dealing with internet and disconnects here, there should be nothing in the design of the network to stop a player from making the key public in the last step of the hand even after a reconnect, as long as he did reconnect in the given time.)

2) instead of relying on commutative encryption, randomly choose another node from the network to act as a "hand seed" and "dealer" for each hand, and probably rewarding that player with a small percentage of the hand pot.

In the beginning of a hand, this dealer generates a random seed, a cryptographically long enough value that will be used as the seed for the random number generator for the shuffling, and makes a hash of that value publicly available in the network. As a hand progresses, player's decisions are broadcasted in the network, and when the time comes, the dealer broadcasts the cards only to those players that are supposed to see them. This is easily done by public key cryptography, i.e. the dealer encrypts the cards a player is supposed to see with that player's public key and broadcasts that into the network.

When the hand is done, the dealer broadcasts the initial seed value, which can be easily checked for validity, since it's hash was broadcasted already in the beginning of the hand.

The winner will only be able to claim the winning transaction if the hash corresponds to the seed, and if the order of players' actions given that seed (and the order of cards in the deck it implies) corresponds to the win of that player.

The dealer only gets his cut if the seed is actually made public in time, and if that seed actually corresponds to it's hash that was made public before.

The problem as I see it is this: is there a reliable enough way to make sure that none of the players can ever cooperate with or even "find" the dealer? Even if the dealer will be random each time, maybe evil-doers will create a botnet of theese dealers and get them together somehow and find a way of quickly finding and communicating with them as a player? (Thus always knowing other players' cards.) Don't know, this needs more thought.

Determining the order of the actions,
There must be a certain way to do this, something to prevent player sending two different actions (fold or call at the same time).
This is very similar to "double spending" problem the bitcoin manages to fix by waiting for confirmations. But block confirmations would be way too slow to do this. I think Geist Geld alternative cryptocurrency has used block speed of 15 seconds, and it has sort of worked, however it is still a little too fast I think, and even if we used 15 seconds, it would still be too slow for poker, because every *action* of every player during a game would have to wait for such confirmations (multiple perhaps).

But! After some thought I don't think we need to use confirmations for those small player actions after all.
There is no valid reason for any honest player to ever broadcast two conflicting actions. By conflicting i mean, say a fold and a bet *at the same stage of the hand*. Of course there will be different actions during the hand, but those can be distinguished by some system of counting.
So, if the network would ever see two conflicting actions targeted to the same stage of the hand from the same player (and since each action will be signed by the private key, that will be easy to determine), it is certain that the player has tried to cheat. In that case the network could simply rollback the hand and punish the player using the mechanism I described before using the fee, reposessing his funds in the pot to the rest of the players (or perhaps even all the funds he had on that table). This way noone could ever win anything by cheating in this way.

The confirmations will probably be used only for transferring coins between accounts, or to/from a table/pot. Most importantly, to withdraw funds that have been "won" from a pot must require confirmations. But that does not have to be superfast, if someone was to wait a couple of minutes before being able to enter a table, or before withdrawing his winnings, that is still not too bad.

Now, as for this whole "another block chain thing"
Given what I have described, this would require a lot of transactions, and thus bloating the block chain even more so than on the main bitcoin chain. Thus it seems to need a built-in clean-up mechanism. So each account in this chain would be much more short-lived. Each X number of blocks all blocks older than Y will be "truncated", forgotten. (Where Y>X.) Economically wise, a small gesell-like negative interest enforced each block seems viable (instead of randomly loosing the money that happened to be in truncated blocks).

This chain will have to be very fast, very liquid, and people will try to keep cashing out directly. It will not be used so much to store the money, but just for the games themselves. By using faster blocks, and not requiring block confirmations for every single thing that will happen in this network, we could very likely make this chain fast enough for real time poker, however that also could make it more susceptible to splitting and other forms of attacks. However I don't really consider real life splitting as an issue, because right now it would take not much less than a meteorite to reliably split a distributed network like this in two halves. It is much more difficult than to firewall some sites like China does, and i believe has not ever been done yet?
Anyway, it is also the fact that this chain will be that much faster and more liquid will also greately reduce the damage, if any kind of attack on it was successfully executed.

To actually transfer money to and from this new chain, some exchanges would have to be created. To use them, you could still remain anonymous, though.

Re: Collusion prevention in decentralized poker.

I like the Rush idea. It doesn't even need to be one hand then shuffle. It could be 60 hands so you get a lot of the feel of a normal game. Or maybe it only assigns randomly and never moves you once in. This would let cheaters move until they bumped into each other, but if move behavior was public that might be okay. If accounts were free that history would be useless. Being required to pay an entry fee (to a random peer?) to be accepted by peers would make it free (or profitable in a sense if there were lots of multis) to play for single accounters (I'm imagining accounts being public keys) but costly for multis.

You could do an all but one rule. Also you could require players post say 20% more than they can play at the table so they always have incentive to approve even a loss.

All this stuff amounts to nothing in terms of a meaningful, credible poker environment.  While there are solutions to subsets of the overall problem, I do not believe it's possible to come up with a all-around solution that won't have holes that will be exploited to hell by determined scammers, and probably end up inconveniencing regular users more than it helps.  Or rather... as solution without third-parties and some kind of centralization...

Seriously, if you even solve this problem 99%, the scammers/cheaters/colluders will figure out how to leverage that 1%, throw a bunch of resources at it, make a significant profit, and most likely cause all sorts of credibility issues for the system as a whole.  And players are skeptical enough, already of online poker...  At least a centralized poker site has the power to police itself, and promote their service with promotions and rake-back deals, etc.  A faceless, decentralized system will need to be airtight in order to survive amidst all the scandals without a PR dept.

I think that it doesn't matter, it can be viewed as sign that he is a very good player ... so he makes many hungry players.

I'm trying to find a good rule to easy catch a cheater from all the statistics, and make very difficult and taking time to build a reputation.

The IP limit and proxy list ( also, with everything else ) can be another good way.
If I see a table with many warning ( many players with the same IP and/or behind proxy, from the shared proxy list ) ... than I'll think 10 times before entering on the table.

How would you know to -1 someone.

Done properly losing to collusion isn't detectable (by the player w/ his limited information) from just losing to bad luck or losing to a better player (who sees through your bluffs and gets out of the way of your monsters).

Even if I see some problems, I'm not saying that someone will be able to see all the rating of every user to another.
I mean, if I ask to see the +1 of an user, I will be able only to see the +1 of the user that I trust ( added as a friend )

Example: If a scammer create 100000 fake account/address, and +1 himself from all of them ... if I haven't any of these fake account on my friend addresses list, I wont be able to see any of these +1.
If I have one of these fake account on my friend list, than I will be able to see its +1 only!
So creating fake addresses and +1 wont be so useful to scam.
( to see 1000 +1 of this scammer I must have 1000 of his fake addresses on my "friend" list )

Example:
After that, we can give some rules as Bitcoin: less than 6 confirmation can be dangerous
Poker: less than +5 can be dangerous.

Anyway, I see the problem of the +1 as you said ... people will +1 others from many stupid and useless reasons.
I still think that a community driver system is the solution, but I'll try to find another way to get the point.

The blacklisting can still be useful as it is on market like silk road, everyone is anonymous, but they still have a reputation.

Another idea:
Instead of the +1, we can have only the -1.
All remaining statistics can be:
- Match played
- Match played with friend "A" ( from friend list )
- Match played with friend "B" ( from friend list )
- Match played with different players ( the distribution of match, to see if someone usually play only with his "friends" / fake accounts )
- How much time he played ( with the NTPs help )
- -1 ( bad votes ) received from all the community
- -1 ( bad votes ) received from friend "A" ( from friend list )

There are many other statistics that can be public ( or friend list related ) and useful to find a scammer and wont go against the anonymity.

Limit it to 1 player per IP address and have a blacklist of proxies?

How about I just spawn 1000 players? I guess you'd have to be forced to pay up-front though, that would solve it.

Would it not work if there is a big enough pool of players and players are assigned to tables randomly? You choose a game, but you get assigned randomly to a table. 

This requires people to make an "identity" system in a anonymized service.  Not only will players always choose to use a new identity for every table they sit down at, but blacklisting a player is pointless when there's trillions of other anonymous identities anyone can use.  Not only that but,

• (1) When do you assign someone a +1?  When you win a hand against them?  When they lose all their money?  When they make a witty comment?  There are plenty of scammers who will go months looking like a regular player without any reason to suspect them.  Frequently it's only long-term statistical analysis that can identify the cheaters -- which is pretty tough when players are constantly changing their identity and there's no central authority to police it.
• (2) There is really no way with this system to avoid having packs of colluders (or 100 identities attached to myself) all +1'ing my other identities.  In fact, almost no matter how you design this idea, the scammers will figure out how to be the ONLY ones with 100,000+ ratings...

The only answer I have been able to come up with for an actually viable pokersystem using Bitcoin is just a normal, centralized one, that accepts Bitcoins instead/in-addition to USD,etc.  That may be a great idea, but it's not what we're looking for, here.

Idea:
Can you add a p2p database where every user can give a +1/-1 to others?
This DB will be common between all peers, and everyone will have a private key and public key.
Then if I chose to give a +1 to another one, I will be able to see his +1 and -1. So I'll chose make my choices to enter or not in a table by seeing these votes.

I'm thinking about a community driven poker system ( decentralized/serverless/anonymous )

You wont have a perfect solution to go against the problem, but you will give to the community all the tools to protect itself and blacklisting bad players.

Example:
After the first installation, there will be some automatic filters and advice, and one can be: "Who is the first player that you trust and you want to add as a friend? Add his address"

I hope that you get the line of my idea

( I get this idea from the Osiris Anarchy forum rules )

I have given a lot of thought to this problem in the past, starting with commutative encryptions for decentralized deck-shuffling (which is possible, btw).  When Bitcoin came out, I thought it was the final piece of the puzzle to creating completely anonymous, decentralized poker for "real" money.  However, the one part I couldn't figure out was how to stop players from colluding with themselves.   The more focus there is on anonymity, the less possible it is to prevent someone from filling 7 seats of a poker table themselves.  Forget other people...if I have 7 windows open at the same poker table, I'm going to run over the other 3 players no problem, and it's going to be more profitable with the near-zero rake of a decentralized service. 

Sure, you can try doing IP filtering, or various kinds of magic, but smart players will get around it, and a poker site with "real money" needs strong credibility and a customer support system.  The more anonymous you make it, the less credible it's going to be.  To make it credible enough, I believe you're going to have to add centralization and remove anonymity -- which destroys the whole spirit of this discussion.

I do find DeathAndTaxes' comment about Rush Poker to be an interesting one.  I used to play a lot of poker, and that was an interesting experiment....arguably I didn't care much for it either, but it does offer a very narrow, niche solution here.  If you can force players to constantly cycle tables, and the player pool is large enough to generally dilute collaboration that exists at any one table, then it will work for those that want to play Rush Poker....

But unfortunately, that's a serious niche.  Part of the edge of a good poker player is being able to sit down at a table (virtual or real) and start figuring out which players are weak and how to exploit them, not tangle with other good players, etc.  Playing a completely generic game with different players every hand is really not going to satisfy any generalized "online poker" market.

I looked at this very seriously about 6 months ago when I stopped playing so much poker and started getting into Bitcoin.  It's a fantastic thought experiment, but I think it's just that.  There's just too many pitfalls to make it actually viable.

Decentralized poker.  This needs some thought.

I think BIP_0011 is a way to make escrows more honest.  To cashout a player would require 51% of players PLUS the escrows consent.  Just relying on BIP_0011 would be very dangerous though as if you sit down w/ a table with 51% cheaters they could use the network to rob you blind.  If someone can they will.  Any network where you sit down and instantly lose unless you cheat will only be popular among cheaters.  

Alternatively you could use BIP_0011 to require 100% consensus before releasing funds from mutual escrow but "greifers" will ruin that.  If I lost all my money I can just be an asshole and vote against releasing any funds.  Granted I likely will never get my lost money back but I can ruin the game for everyone else.

I don't see a way around the need for an escrow but if the network supports multiple independent escrows and uses multi-party signing I think the risk of a "bad" escrow can be reduced.  Even at an escrow fee of 0.5% poker is a high cashflow business.  You are essentially collecting 0.5% of average player's stake every day.  

How much is that?  A lot.  Take a site like PokerStars. Has about 7,000 players online and playing at any particular time.  Average buy-in is probably $25.  Say average player sits down to 10 games per week.  That's 0.5% * $25 * 10 * 7000 * 52 =  ~half a million per year.  Even at a 0.1% escrow we are talking a hundred grand.  Obviously for a smaller poker rooms room revenue would be lower but at any particular time the escrow only has the funds currently in play.  If the escrow involves multi-sig then the amount of assets at risk would be a fraction of total assets (depends on how you setup the multi-sig).  This limits the amount they escrow can steal while being legit is still lucrative and would continue to grow with popularity (the whole risk vs reward).  Ironically pushing escrow fees too low actually upsets risk vs reward and makes stealing more likely.

That is a harder problem.  This is actually where a good poker network earns it rake.  Catching cheaters can't be done w/ software alone.  It requires human fraud specialists and the ability for the poker operator to acts as final judge.  Yes cheaters do get through and sometimes innocent persons are wrongly accused of cheating but the combinations of heuristic software and good fraud detection employees is the biggest benefit a poker network can provide.

The only way I see a decentralized network being able to handle collusion is w/ a game like "Rush poker".  For those who don't know Rush poker (an invention by Full Tilt Poker) works on the premise of each hand you play w/ different players.  You join a Rush "pool" and are assigned tables randomly.  When you fold or the hand ends you are immediately assigned to another random table.  I hate it but it is very popular.  The popularity comes from the speed.  Since when you fold you go into a new hand almost instantly you get to do more playing and less waiting.

Rush poker would make collusion very difficult assuming the number of legit players is large relative to the number of players in the largest collusion gang.  Say a gang of 8 colluders tries to cheat the network which has 100 players at a particular stakes.  They have a decent chance.  Now the same 8 into a pool of 8,000 players makes colluding essentially useless.  Rush tournaments could also be created although if the colluders survive long enough (or starting pool is too small) then as the field narrows the risk of collusion rises.

Normal poker when players can choose their seats likely can't be properly policed by a decentralized network.  Poker is at its most basic a game of incomplete information.  Player gain (legitimate) advantage over other players by using proper deductive reasoning to fill in the games.  Information is the most value asset in the game and those who can/will share information have an unfair advantage which is difficult to detect.

I hope that will be found a way to totally avoid escrows ( totally decentralized and disconnected from thirty party ).
Is BIP_0011 the first step?

If you are going to use an escrow this is the way to do it. 

Essentially when you sit down with $x the $x gets escrowed and you get x play money chips.  The network of players can manage the play money chips.  When you leave whatever you final chip count (checked by getting consensus of all other players) is what the escrows pays out.  Same thing happens for any rebuys.

Thus at any particular time the amount in escrow = amount of play chips in play. 

I think an escrow could do it for 1% or maybe less as it wouldn't require any manual intervention just smart programming to avoid tricking the escrow.  That is the weakest link.  If I can trick the escrow into letting me cashout more chips than I have well I can rob the other players blind.


Having all players in the hand sign each hand (including a ledger of current balances) would go a long way towards ensure the escrow computer isn't "tricked".  The details on exactly how to do that should be subject to open and robust debate as that is the most likely point of attack.

Could the M of N contracts be used for this ? https://en.bitcoin.it/wiki/BIP_0011

You would 2 people out of the N to transfer payment i.e. the winner and the site operator.

We probably can't assume at least half of the table is genuine, can we? That would make things easier… Maybe half of the table's processing power? Or half of the poker network's processing power?