Help with decentralization of poker?

PokerPlayer

I admit I can only envision a solution, and can't show any proof. And that I'll never likely have any decent technical grasp of all this, but I do think that we have the solutions needed for decentralizing poker. I think the real issue is moving the players community behind the idea. Which means, getting credible people (developers?) to understand a provable solution. It probably involves a working model/product and a shift within the players community.

But if it can be shown that there could be a working decentralized game equal or superior to the best centralized sites, then the players can imagine a game with their own rake model and incentives to come up with cost saving solutions.

To me that means the players community today pays x dollars a day in rake to 3rd parties, and they stand to save that money by developing (and funding) a decentralized project. If I understand ethereum correctly, their is mutual incentive for the players community to adopt ethereum to the point of it being Epoker. It would be nice to add the poker community to the ethereum network I am assuming? And so if a solution could be presented that is verified and understandable their should be $100,000's or millions available for its implementation (depending on the solution and contracts for funding players might flock to it).

I just really think the key here is this can only work if the players buy their own game. (The only other possibility is an owner sells the players the idea with a working product and phases out eventually, but that is trivial anyways.)

I described it the best I could, I can barely understand any of the papers, but it seems to me that with decentralized chess and cyberdice, and the players community developing incentives and rules, ethereum can specifically address decentralized poker in every way that is significant to the player (but not necessarily to a 3rd party private interest).

Does the player community bring value with them? Extra computing power? Liquidity of ether?

Maybe you don't need to read my writing, but point me to someone who has shown this or could answer this?

I'm trying not to sound crazy but I feel like this community might not fear out there ideas.

http://www.scribd.com/doc/225582000/Epoker-as-a-solution-to-DPoker

StephanTual

Interesting start - the problem with Poker on a blockchain is that everyone's cards would be known by everyone at all times (no means of obfuscation) - do you have ideas on how to solve this conundrum?

PokerPlayer

Thank you, this is what the players need to know, we need to know the technical problems from your side so we can translate them into what it means to the poker community. Because obviously the solutions need to satisfy both.

I am not technical, yet I seem somewhat crucial for the sole reason I have zero limited beliefs.

I will take what you posted alone, to networks I have and perhaps they can instantly remedy it...but i will give some random thoughts in case it inspires more issues and points from you, giving me more questions and possibly you as well.

We just want to write the line by line (text) turn based game play as it happens. So my understanding would be the only issues is the possibility of reading the hand history in realtime (i have ideas for this anyways). Maybe I have an incorrect view but my thoughts is players broadcast their move (line of text) to each other AND the blockchain simultaneously.

I feel this can work because if for example we used msn groups for text based poker, and had a public forum as a ledger, you should able to facilitate a perfect poker game. Players announce their move in the msn chat and write to the forum ledger. This way all players can verify the authenticity of players and their actions. And they can verify if someone is not posting simultaneously to all the players and the ledger.

My understanding of cyberdice is that we have separated the deck protocol in a way that it doesn't need the ledger to function.

So i think i mean to say, and i hope it came out clear. We should be able to play dpoker (or epoker) in the same way as d.chess + cyber dice, and the players only new age request is the final results of each hand ends up on a ledger

Any thoughts are greatly appreciated, I feel once we can sort out all the road blocks, i can convince many players to fund this since in the long run it will make them money and after all they are poker players that hunt for +ev investments for their monies

PokerPlayer

I should clarify what i mean by broadcast to the players AND the ledger:

Players can use any messaging service they want for their game play, it doesn't need to be secure or trustable in any fashion, in fact it really only needs be fast and able to be sent out to all parties on the table and a few random anonymous parties.

This works as long as the player to act also posts to the block chain their intended move.

So then players can easily cheat, however there is zero incentive to do so because they will ALWAYS get caught. *

Then games are free to run smoothly over an insecure style group messenger service.



*and the players community will dramatically reduce this players integrity rating because its a perfectly obvious and provable cheating method. We are creating a game where you need that integrity rating to participate.

PokerPlayer

Part of my understanding came from the E white paper:

"6. Peer-to-peer gambling. Any number of peer-to-peer gambling protocols, such as Frank Stajano and Richard Clayton's Cyberdice, can be implemented on the Ethereum blockchain. The simplest gambling protocol is actually simply a contract for difference on the next block hash, and more advanced protocols can be built up from there, creating gambling services with near-zero fees that have no ability to cheat. "

Did i understand this incorrect, and when we say gambling its not meant for card games?

PokerPlayer

good luck launching.

StephanTual

Thanks @PokerPlayer‌ . Regarding #6 'peer to peer' gambling it's definitely within the context of a game of dice or similar, not necessarily games that require 'secret' information to be validated then revealed (i.e., deck of cards).

That said, I love a good game of poker and am interested in researching this a bit more myself. I'll keep you in the loop via this thread or PM when I get to it Cheers!

robmyers

Create a one-time account for each hand, send hashes of state from that account, reveal the private key when you wish to reveal that hand?

PokerPlayer

Yes that seems much like I understand it. And that is how the cyber dice concept works I believe.

Maybe its not relevant but it seems to me we can note that a poker hand only lasts a few minutes, so the encryption can be made to be 'crackable' as long as it takes X amount of time to do so. Don't know if that relates, maybe we are worried players won't share their keys? Again tho, as along as you have the possibility to catch cheaters always, then there will be zero incentive to cheat.

Here is one post on card procedure from https://bitcointalk.org/index.php?topic=362901.0:

A. Basic Poker:
There is a great cryptographic method called 'Mental Poker' which enables a set of cards (or other set of values) to be shuffled by multiple people without using a trusted third-party.
-Alice starts out with an unshuffled deck.
-Alice picks an encryption key A, and encrypts all cards using that key.
-Alice shuffles the deck.
-Alice passes the shuffled deck to Bob.
-Bob does not know what order the cards are in, since he doesn't know A (and thus doesn't know what values represent what cards in the new stack).
-Bob picks an encryption key B, and encrypts all cards using that key.
-Bob shuffles the deck.
-Bob gives the deck back to Alice.
-Alice now has no idea either about the values/positions of the cards.
-Alice uses her key A to decrypt all cards. (though she still doesn't know the values since Bob's key B is still in place)
-Alice encrypts all cards using a special key for each card.
-Alice passes the deck to Bob.
-Bob decrypts all cards. (though he still doesn't know the values since Alice's many keys are in place).
-Bob encrypts all cards using a special key for each card.

The deck is now shuffled: All players can see the stack, but they do not know what value is what card, since all players hold a key needed to decrypt it.
If the protocol decides that a certain player should be able to see a certain card, all players give that player their keys for that card.
Now only this player has all keys needed to look at the card.

This can be used to implement most of the poker scheme.


Here is the full paper on mental poker http://www.dc.uba.ar/inv/tesis/licenciatura/2010/lerner
And 2 more: http://crpit.com/confpapers/CRPITV21AZhao.pdf
http://people.csail.mit.edu/rivest/ShamirRivestAdleman-MentalPoker.pdf

PokerPlayer

I am just putting these here for reference, seems to be exactly related:

http://bitcoinmagazine.com/9671/ethereum-next-generation-cryptocurrency-decentralized-application-platform/

http://blog.ethereum.org/2014/05/14/what-is-ethereum-project-platform-fuel-stack/

"A peer-to-peer fast messaging protocol, will enable the user interface to reflect such changes, and will facilitate communication among different DApps and among users."

"At this point, however, it is clear that contracts for difference are really only one special case of a much more general concept: contracts for formula. Instead of having the contract take in $x for Alice, $y from Bob, and return to Alice $x plus an additional $z for every dollar that some given ticker went up, a contract should be able to return to A an amount of funds based on any mathematical formula, allowing contracts of arbitrary complexity. If the formula allows random data as inputs, these generalized CFDs can even be used to implement a sort of peer-to-peer gambling."

"Each Ethereum contract has its own internal scripting code, and the scripting code is activated every time a transaction is sent to it. The scripting language has access to the transaction’s value, sender and optional data fields, as well some block data and its own internal memory, as inputs, and can send transactions. "

"A very basic protocol would simply be a contract for difference on random data such as a block hash"

knircky

I think the hidden + public info has been shown to be solved with the algo that was posted above.

We now need to be able to bring the other parts that make up a poker solution together. I think ethereum could be quite helpful.

Poker could also really catapult any BTC type technology. Poker could be a killer app for us. There is 3-5M flowing into the poker economy every day but most of it is raked away. So this could be really beneficial for both economies. And poker player might be able to switch faster than other parts of society.

lunchtime

I like that mental poker breakdown. The deck may have to come encrypted firstly before A is applied though, otherwise the first player could see the state of the deck while they encrypt it before handing it off. A deck could be generated, encrypted, passed around to each player who puts a set of encryption keys one for each card, shuffles between eachother, then before gameplay starts the master key decrypts everything and now if I had cards x05 and x25 everyone gives me their keys for those two cards so I can see them. As community cards are played everyone decrypts them so all may see. If one person doesn't give up their key, they are removed from the table and a new hand begins.

PokerPlayer

This is what I haven't been able to understand

1)If Hero makes a decision, hero needs to know that his decision will be validated vs 8 other colluders.
2)If colluder 1 makes a decision Hero needs to know that villains decision will be upheld in light of the 7 other colluders.


And I want to know if this is a simple solution?

gSf(m) = S(m)

S is a digital signature. f is the blinding function, and g an unblinding function. The blinding functions are usually based on a secret random number called the "blinding factor". m is another random number, a unique identifier which can, for example, refer to an instance of some object.

The idea is very clever but very simple. It may be counterintuitive because the simplest physical world metaphor of this highly useful e-commerce primitive sounds worse than useless: Alice can get Carol to sign a blank check! Here's how:

(1) Alice generates m and blinds it. "Blinding" is just a one-time-pad encryption to oneself, f(m). She sends this to Carol. This is like taking a piece of paper and sealing it inside an envelope which Carol can't open or see through.

(2) Carol signs it: Sf(m), and sends this back to Alice. This is like Carol signing the outside of the envelope.

(3) Alice unblinds it: gSf(m) = S(m). Carol has also signed the paper Alice put inside the envelope!

The genius behind this discovery: cryptography guru David Chaum. The brilliance lies in step 3: Chaum discovered that some signatures have the property of being "commutative" with the blinding functions: Alice can strip off the blinding in the reverse order which the blinding and signature were applied, leaving just Alice's signature of n. It is as if Alice put a piece of carbon paper inside the envelope!

In particular for RSA signatures, with public key (pq, e) and private key d, the blind signature functions are the following modulo pq:

S(x) = xd
g(x) = xk-1
f(x)= xke

We can check that the blind signature property holds: gSf(m) = (m(ke))d * k-1 = md * k * k-1 = md, which is the valid RSA signature of private key d on m


And then on top of it I feel like this would solve the above completely:

http://gavintech.blogspot.ca/2014/06...view=timeslide

And specifically the oracles outlined here https://github.com/orisi/wiki/wiki/Orisi-White-Paper

I've felt this was the solution for awhile but not sure if it outlines what I am thinking.

There are 4 issues outlined:

The oracle can be hacked.
The oracle process is opaque - we can never be 100% sure of the oracle’s program or of what it will output.
The oracle can disappear between the transaction setup and finalisation.
The oracle may be bribed to deliver faulty results.

Yet it seems to me that if we send a verification out to n anonymous nodes (as oracles), then we can control the security of it by increasing in. This is important because the poker can be done this way anonymously and so there cannot be a way to collude other than in a super fashion that does not serve the attacker in any profitable way.

Because only malicious intent is left its seemingly impossible that someone could have the economic backing (lack of incentive) to carry it through.

Oracles can be kept honest and we can create a greater anonymity (more collusion proof) by sending out false verifications, that the players pay the oracles to get correct.

jesus666

Hey PokerPlayer. Been looking into the idea of implementing mental poker with an ethereum contract used as a mediator and I think I'm pretty close if not already there in terms of conceptualising it. Would be nice to bounce these ideas off of someone.. I'm Konstantin Kudryavtsev / mephistotm on skype, you can find me on most ethereum channels

PokerPlayer

Maybe someone could take a look at this, just a small insight i had. seems to approach mental poker with a different basis. Sorry for the psuedo math/tech talk...sometimes concepts come to me and I don't have the lanugage to explain. Really felt like things made sense to me here, and everything got wrapped up.

Any input is appreciated even (maybe especially) from non poker players.

The hand starts with a timelock transaction escrow with %'s release to each player based on the final line of a hand within a time period greater than the possible time period in which the hand might last.

For n players, each player Pn chooses a number Xn between 1 and 52! We “label” each card in the deck universally between 1 and 52, and have a universally known 'order of permutations' in regards to ways the deck can be arranged and agreed on.

This number is encrypted by each player and written the block chain in a particular order related to the position each player sits in the hand. That is to say order seems to matter in some respect and so it is not commutative.

The shuffled state of the deck then is P1 + P2(X2) .....Pn(Xn) = Si, Where the highest possible number (52!) + 1 returns the first permutation of shuffle states.

In this way the deck can now be understood in its “shuffled” state Si,

We now have a shuffled deck in the form of a number that represents a certain permutation between 1 and 52! permutations.

We don't need a common random trust-able seed or to “draw” cards, but rather it can be seen for any state Sx “C1” is to be “dealt” to the first player to receive a card, C2 the next person and so on. Since the state of the deck is random to everyone it really matters not the “order” in which who receives which card, yet it is important for future verification that everyone has previously agreed to this order.

So we might choose a standard such as players 1-n receive respectively cards C1-Cn, and then for their 2nd card (Nl hold em) players receive their 2nd card C(1+n),...C(n+n). If C(n+n) then was the last hole card to be “dealt” then C(n+n+1),...C(n+n + 5) positions would contain the flop, turn, and river respectively.

Dealing is simple. Imagine each player has 52 pieces of paper, corresponding to their own unique “color”, which is transparent only to oneself and completely opaque to each of the other players. Further picture the entire shuffled deck face up in a line (C1 to C52 but in a shuffled order) in front of the players, and each player covers each card with their own colored pieces of paper. No player has seen the order of the cards. In order to deal a card to a specific player n, each player that is not n, simply removes their colored piece of paper leaving only the card with the piece of paper on it that is transparent to n but opaque to every other player.

To show a card to the community such as the flop/turn/river, the process is identical but this time all players remove their “papers”, thus revealing the card to everyone.

We might then take another metaphorical view of this to understand further. Imagine floors to an apartment type building with n floors and each floor containing 52 rooms with the exact same layout on each floor. Each player has their own floor, player 1 is on floor 1,....player n is on floor n. Player 1 uniquely connects a pipe from each of the 52 rooms on the bottom floor through each of the 52 rooms on their own floor and up to player 2's floor in any random manner he is comfortable with. Player 2 cannot see which of the rooms from player 1's floor that each pipe comes through. Player 2 connected each of his rooms up to the next floor and the process continues until the last player n connects his pipes up through to the rooftop. Thus each player has had a chance to randomize the “flow” without being able to see the randomization scheme of any of the other players.
Since the game is played on a blockchain all previous “actions” or lines in a hand history, can be thought to as having reached “consensus”. The remaining issue in this regard then is only with the present decision to be made and accepted to the blockchain. A malicious villain may choose to either disconnect or not “reveal” a certain card needed to further game play. There might be two interesting solutions to these issues. We might think of “disconnecting” as an honest act, and not revealing a card as a malicious one.

In regards to malicious players, there cannot be much incentive to defect in this fashion, especially with even a weak single unique identifier/web of trust system in play. A villain does not stand to “gain” any more than disrupting a certain hand and causing the hand to never have been dealt in the first place (all buyins returned). Furthermore, the initial time locked escrow can be set so that no player receives their share of the equity without passing in their public key at the end of the hand. What is interesting then is that in the case of a malicious failure to facilitate the game, assuming it was the case villains equity had fallen less than an equal distribution of the equity (ie the cause of their defection), the players left in the hand might agree to arbitrate the “dispute” by running the part of the hand history that is already written to the blockchain, through a third party equity analyzer (which has little monetary incentive to defect itself or be hacked). In other words the equity in the pot can be distributed as an “all-in” case to the players in the hand, mitigating the “reward” for defection.

In the case that a certain player disconnects (whether honestly or dishonestly), the remaining players can choose to reshuffle the deck (minus any community wide known cards) and continue a new hand as a subset of the initial transaction, with the same parameters of all of the actions up until the point in which one player disconnected. This brings up a small solvable issue-how do the players remove blockers from the deck of the cards that each of them are holding in their “hole”?

This can be done by each player choosing a random number between 2 and R where R is the number of cards not yet seen by the community and secretly writes this number to the block-chain That is too say if hero holds 2 cards that should not be in the deck then there is 2 of R chances that their hole card will be dealt to the community. But hero will have to protest and ask the card be shuffled back into the deck (starting the shuffling process over), so he simply needs to balance this frequency of request with a proportional amount of “bluff” requests. This solution can be structured indefinitely for cases in which the same hole card is drawn which may or may not be the card in hero's hole, and so the “edge” to be obtained from a reshuffle request is brought down to an acceptable level.

It also might be significant to point out the encryption on each players “randomizing” number need not be stronger than the amount of time a given hand takes to play. The is to say the encryption needs only last for say 24 hours worth of brute force (where brute force harness can spend < reward of attacking) and so its possible a “softer” encryption might then allow the hand history to be revealed and “adjudicated” without the malicious player ever giving up their “key”.
EtheruemPoker is offline Reply With Quote

PokerPlayer

This would be a better way to kill hands if the above has any worth:

If we imagine all 52! permutations as an arrary of arrays representing all deck combination, you might actually be able to reshuffle without putting the cards back in the deck in the case that one of the player keys is failing to be presented (obviously while folding/killing their hand).

Lets say the random choice for deck permutations between 3 players lands on sate Sx and player 3 has broken protocol and must be booted from the hand. The first 6 cards of the deck state were dealt to the players and the next 5 belong to the flop/turn/river.

Players 3 cards reside at C3 and C6. Let's say for this example only the flop was dealt which is C7-C9. Then upon player 3 forfeiting his hand (dead), the new shuffle procedure only needs to be changed to consider a range of states in which C1-C9 remain the same (without revealing what actual cards reside at those ranges).

PokerPlayer

It seems there would be no reason to "encrypt" the cards. Each players has their individual chosen deck state. The true state of the deck is the addition of each state in the order the players are seated written to the block chain. If player 1 needs to be "dealt" the first card each player gives the first card of their state and only player 1 with his last C1 card from his state can find the vale of the true deck state at C1. Cards are ordered from 1-52 where for example 48 + 5 would equal 3 (starting over after 52).

Paul

knircky said:

I think the hidden + public info has been shown to be solved with the algo that was posted above.

We now need to be able to bring the other parts that make up a poker solution together. I think ethereum could be quite helpful.

Poker could also really catapult any BTC type technology. Poker could be a killer app for us. There is 3-5M flowing into the poker economy every day but most of it is raked away. So this could be really beneficial for both economies. And poker player might be able to switch faster than other parts of society.

I agree. Poker could be a killer app for Ethereum. There is a need for a trustless internet poker game. Does anyone remember the Full Tilt poker mess. When the were shut down by the government they did not have the money to pay all the players bc they were acting like a bank and doing other things w the deposits. And there have been multiple times when people running the poker sites cheated and looked at the cards go the players in the big money cash games. So pros are reluctant to play big money cash games online now. Plus what people were saying before about the rake - that it could be improved. So if people could save money and not be worried about having to trust the poker site it would be in their best interest to pay the ether required to make the game go. Poker bots colluding cards is also a problem with online poker- I wonder if Ethereum could somehow help with this as well.

PokerPlayer

cleaned up my thoughts, pass to anyone you know that might have insight thx!

http://www.scribd.com/doc/240518193/Satoshi-Paper-A-Decentralized-Secure-Mental-Poker-Protocol

FrankHold

Hi thank you tor all the information, here is a small program how I could think it could work, to save the cards on the block chain. (only 3 player only flop)

khanacademy.org/cs/deck_01/6473950051958784

Save for each possible combination of players which could see the flop a different set of cards. Encrypt the cards with the keys of players who would see this particular flop, save the encrypted cards on the chain and send a key to each player. If two players are in the flop round they have to send there keys to unlock the particular flop.

FrankHold

There is a Problem: If 2 player cooperate they could read the random generated community cards as if only they would be in the flop. This is not directly a problem, because if a third player would be in the flop a different set of cards would be chosen. BUT they have the knowledge of those cards and can be sure that those cards are not the hole cards of any other player. If more than 2 player cooperate the number of cards they can rule out as starting hand increases.

Also the described reshuffle has the particular problem with 2 players – if a card on the river is rejected my opponent know one of my hole cards.

Right now the only save solution I see is, if a player folds/leaves he has to give back his key. If he does not do it the round has to be terminated and the play has to pay some kind of fine/deposit.

PokerPlayer

Ah cool, I ditched this for a bit because I thought I found my issue, but I still have some ideas that might be valid.

I checked out your code, I am not too technical so it will take me a bit, but I have someone I chat with that will look at it with me. I think your attempt is different than mine which is good, but I am just checking to see if you think its different too?

I think I noticed, that you have situations where only 1 player sees a flop which is arbitrary, but that doesn't matter for the example.

How do player get "hole" cards that they don't share with each other? We have to make sure the cards they don't share are also no longer in the deck?

Thx for sharing, please stick around maybe we can get different minds wrapped around this problem!

PokerPlayer

This is the simplest explanation of the version I am working on now:

We can imagine players have a universally ordered “cheat sheet” of all possible permutations of a deck of cards (later this can be an "agreed up" formula. Each permutation has a number from 1 to n! for an n card deck. We call a “state” a certain permutation or order of cards.

For a 3 card deck the cheat sheet works like this:
1 2 3 4 5 6 <---- player initially each chooses a number 1-6
A A K K Q Q
K Q A Q A K
Q K Q A K A

Each player secretly picks a random number, and puts it into the function. Each individuals' choice corresponds to a certain permutation (state) from the cheat sheet. The function adds the numbers revealing the sum only to itself. This sum gives a number that corresponds to a certain deck state. This deck state is the permutation of cards the players will use for the game (the order the cards lie in the deck).

Once the function knows the deck state it can then compute an “adjustment” key (explained below) for each card in the deck. The adjustment key is n adjustments (1 for each card in the deck; 3 for this example) the players will need to apply to the “cheat sheet” in order to reveal (“decrypt”) each card.

To reveal a card to the community each player gives their own corresponding card from the initial random number they chose. If a player is to draw a card that others shouldn’t see, they simply collect all other players “key” card but don’t reveal their own.

Example:

2 players are HU with a 3 card deck (A K Q)

3 card deck "cheat sheet":
1 2 3 4 5 6 <---- player initially each chooses a number 1-6
A A K K Q Q
K Q A Q A K
Q K Q A K A

P1 chooses random number 2 deck state [A Q K]
P2 chooses random number 4 deck state [K Q A]

**************************************************
Function computes 2 + 4 = 6
Deck 6 is [Q K A]

Functions observes P1(deck 2) + P2 (deck 4):

For a 3 card deck [A K Q] we can think of Q=1, K=2, A=3
A + K = K
Q + Q = K
K + A = K

The sum of P1 and P2's individual cards gives a deck [K K K]
however we are looking for deck 6 [Q K A]

So the function computes the adjustment from [K K K] to [Q K A]

K + C1? = Q C1 = K
K + C2? = K C2 = A
K + C3? = A C3 = Q

The function outputs the "adjustments" [K A Q]
****************************************************

P1 and P2 know the adjustments are [K A Q]
P1 chose number 2 which is deck state [A K Q]
P2 chose number 4 which is deck state [K A Q]

Only the function knows deck 6 is the true state deck 6.

To reveal the first card:
P1 gives P2 C1 "A" from deck state 2 [A Q K]
P2 gives P1 C1 "K" from deck state 4 [K Q A]
Adjustment C1 "K" from adjustment output [K A Q]

(Remembering Q=1, K=2, A=3)

C1 for deck 6 = P1C1 + P2C1 + AdjustmentC1
= A + K + K
= Q

The players reveal Q is the first card in the deck.</p>

The question is can P1 distinguish P2's cards based on the adjustment outputs, and their own initial deck choice.

In this example it might be easier, but the question is of course about a 52 card deck with 23 cards being used for 9 players.

And then the question is for n players can n-1 players collude and use the adjustments to determine 1 players initial deck choice.

FrankHold

Hi nice to hear from you again. I have to think it trough.

If we find a solution, than we would have a solution for the random number problem too. https://forum.ethereum.org/discussion/546/lll-question-random-number-function#latest

But I am a little pessimistic at the moment.

"Each player secretly picks a random number, and puts it into the function."

The problem is the contract (function) can not hide anything and only one player at the time can call the contract. This means the contract has to store the randomly generated number. Therefore everyone - at least the last player - can see the number.

Because we have not only the problem of generating a random number but also the number should be only known by the contract itself. Otherwise you could figure out the starting hand of the player.

With a random number would be the rest straight forward.

PokerPlayer

We were asking if it can take encrypted inputs?
But maybe I need a different understand of ethereum from the start.

FrankHold

This would be nice, or a storage space which can only be accessed by the program itself.

It is discussed, to import as example weather or stock data in ethereum, maybe this could be a source of randomness.

I am sure someone will come up with a solution, but I doubt it is me.

FrankHold

Hi nice to hear from you again. I have to think it trough.

If we find a solution than we would have a solution for the random number problem too. https://forum.ethereum.org/discussion/546/lll-question-random-number-function#latest

But I am a little pessimistic at the moment.

"Each player secretly picks a random number, and puts it into the function."

The problem is the contract (function) can not hide anything and only one player at the time can call the contract. This means the contract has to store the randomly generated number. Therefore everyone can see the number.

Because we have not only the problem of generating a random number but also the number should be only known by the contract itself. Otherwise you could figure out the starting hand of the player.

If the contract could just call a random number then the rest would be straight forward.

________________
Here is a poker program I wrote with ethereum in mind. I stopped because of the random number problem. Therefore it is not translated. You can only send two values to the program. A seat number and a bet. Maybe you can figure out how it works - just click randomly.
khanacademy.org/cs/ep03/6722018477342720

PokerPlayer

Yes I am not sure that I have proposed something that takes your point into consideration, yet I intended to.

The idea is the "contract" gets encrypted inputs, and the output must be decrypted by the players together.

Then the point might be made, that no contract is needed, but its simply part of the overall verification of the game flow, proof.

As long as encrypted inputs can still be "summed", then they can be hidden yet useful...

I'm still trying to find out if this is the possibility.

FrankHold

Would be nice, maybe try mintchalk.com/
It gave me a better insight how it work.

My last try to "shuffle a deck of cars" was
mintchalk.com/c/99b06
(It was just a try, does not mean it really works.)

Each player sends a shuffle order and a encryption key. In the end you could have a encrypted shuffled deck.

If all player work together they could decrypt the deck again.

But I did not jet found a solution that the program could do anything useful with encrypted deck or decrypt only a single card instead the whole deck, because the program does not know the key.

PS: I have today a longer train raid, so I have some time to think again about the problem.

FrankHold

Maybe we have to split the task. Let ethereum do what it can best – transfer and organize the money flow. And let a poker routine run on a classic server outside of ethereum.

Jasper

What if a single party plays server, initially cryptocommits a random value, H(R) onto the contract. As the game runs, uses his random value combined that with RANDAO, and signed messages from players about their moves, which those players themselves tell the contract. He tells the other players (confidentially) what their cards are. When the game is done, he reveals the random value R, and indicates the claimed result to the contract. At that point everyone can calculate the progression of the game to verify. If it does not check out, they can challenge, and tell the contract to re-calculate the game. When they got the messages about which cards they had, those were signed aswel, so they can claim that the server told them which cards they had incorrectly.

Of course, the server still knows everything during the game, so he could cheat by telling other people. However, the state of the game does not have to be a state of a deck. It could be a probability distribution as-if the game was played the way it was. In the case of a deck where the cards are distributed one by one, the server only needs to know which are still in the deck, and random ones are picked out based on the next (yet unknown, as they come from RANDAO)random value.

The server now still knows who has which cards, and i dont think you can stop players from telling each other what cards they have. Really the best that can be done in-principle that the players just know what they aught to know according to the game. I.e. if cheating is sharing that information, afaik there is nothing to stop that. Well, you could try ensure that the origin of the different players is truly a different party, to limit the possibility of collusion. You could also try keep players to the same account and do statistical analysis, but probably people ran away with a lot of money before you have enough to 'convict' any of them.

Also there is the issue of timing. Preferably, when people indicate their moves, the game can immediately continue. However, if you dont want the server to know what is going to happen, you want the next move to be the after-the-next block, or a block that the players dont yet expect has been created yet, anyway. The random values become clear each block.

Sorry for not incorporating the stuff said in this thread, particularly from PokerPlayer's comments. The above would be a bunch better if the server did not know everything but order of the current stack of cards in the scheme.