If we could establish a dealing method that could allow for players to validate that the deal could not have been manipulated, than this could be a huge benefit for all concerned. The question of games being rigged or not would no longer be in question.

I may have most of a solution that may work but there’s a couple things I need help on. In this case for the pseudo-random number generator algorithm discussed below. I'll provide a simplified example to setup my questions at the end.

Example
Let’s start with a large data base of “pre-shuffled decks” generated before hand and tested as random. We'll define a shuffled deck as being 52 unique integers in random order. This will include encrypting the card values but that's not important for the discussion right now.

There will be 1 database for each table number used for a given 24 hour period, so that the same deck could not be repeated on different tables. These data-bases could be copied and held by multiple third parties and later displayed on a public sites that the players would have access to after the 24 hour period. This would prevent any database from changing or checking back to an independently held copy would reveal the change.

Next we assign a serial number to each deck from 1 to the number of decks in the database.

During the 24 hour dealing cycle, as each player joins a table, they would enter in a 3 digit code that could not be known by any other player. The sum of all player codes plus a time element that had resolution down to the second would generate a seed value. The time element could be a 24 hour clock or a 24 hour second counter.

This seed value would be plugged into a known PRNG algorithm to determine the serial number of the deck to be dealt each hand. After a session, all player codes and time indexes would be made available to the players could re-generate the same serial numbers and then looked up to find the deck within the copied DB in order to recreate the same deal. If it matches, we can see that the deal wasn't manipulated.

This is because the players will see that the serial numbers could not have been influenced by the poker site and that the decks came from a database created prior to the hand and could not have changed. Therefore proving the site could not have influenced the deal.

One part that I'm stuck on is the PRNG algorithm used to pick from a range of serial numbers. The conditions for that PRNG would be:

• The algorithm must be must be independently deterministic. Another words, the the players must be able to recalculate the same results later.
  
• The SNs generated must be non-repeating so that all deals within the 24 hours will be unique.

What this means is that if the algorithm were to repeat a result within the defined time range, than it couldn't just bump the result to an unused number because then players back checking that specific deal would come up with a different result. I haven't been able to find an example that would fit these conditions.

Questions

1. Is such an algorithm possible?
2. Would it need a database that would be much larger than the number of hands used?
3. Could it use a DB size that was only large enough to make sure we didn't run out of hands dealt in a 24 hour period?
   For example
   2 hands/minute * 60 min * 24 Hrs = 2,880 Hands.

I actually think even if you come up with something iron clad, it won't be used/accepted by the public. Did you know that cryptographic protocols for electronic voting were established loooong ago (like, I dunno, the 60s?) that would make it trivially easy to tell if the vote was manipulated? We don't use those, because the general pop wouldn't believe that they really worked. For similar reasons people would rather attach a gif with my signature to a document instead of a cryptographic signature, even though one of those proves I signed the doc and the other does not.

Another problem is that this would essentially expose everyone's hand after the fact, which a lot of people would not like.

Why would you want to prevent the same deck from being generated (it's extremely unlikely, but it could happen in "real life")?

Your "serial numbers" for decks would have to be either the actual decks or something that could generate the deck with an algorithm. There are 52! possible deck orderings, this is 8*10^67, i.e. larger than the number of atoms in the universe. Unless by serial number you just mean a database ID that would only be valid for the 24h period.

I think something interesting that is related to your thought is that you could actually tell the table what the next N decks were, in encrypted or hashed form. After the fact you could verify that the decks actually hashed back to what you were given. There are a lot of hash algorithms that are extremely difficult to reverse into their source data. With most good hashing algorithms it is *extremely* difficult to find 2 source documents that hash to the same value.

Most of what I described was simplified for the purposes of posing the questions I was asking. There were details I left out that were specific to most of the points you made.

I think your correct if it involved a method that was too complex for the layperson to understand. However if it were a method that was simple enough to be self-evident for most, than I think most would prefer it to just blindly trusting a site doing a fair deal. Kind of like using ping pong balls in lottery machines as being as transparent and self-evident as possible.

I think using a transparent simple algorithm determined by player codes and drawing from pre-existing published database of randomly ordered decks would be simple enough for most to understand that a site could not manipulate any cards. Especially if a player could essentially recreate any deal in a session. When most understand it, eventually it would just become a commonly understood fact that most of the rest could accept. There will always be some portion that are not able to think reasonably but that's always going to be the case.

Actually I would only show cards that were revealed in the DB but this would still go a long way towards showing non-manipulation since all showdown hands (especially the winner), all board cards and hero cards would be seen to be free from manipulated during the game.

As far as the mucked hands go, it doesn't matter that much. Also for the hands that won without showdown, those could always have been presumed to be ATC some percentage of the time. Just the extremely high potential of any manipulation showing up would be pretty strong evidence.

Also regulators could have access to a full database to verify nothing irregular was going on just by running full comparisons between results and DB. to validate it 100% pretty easily.

Even doing some number of spot checks for randomness as another post process would be pretty easy on static databases.

Not that it would be necessary at this point but you could even allow players to check a limited number of hands against a full database maybe limited to 2 or 3 hands/month potentially allows millions of spot checks by players.

So much more reasonable than playing and studying massive hand history samples.


Yes, this.

Although, I think it's interesting that a full database is not necessarily out of our reach for 10 handed holed'em when you consider only 25 cards are used. So C(52,25) =4.7E+14. That's still a pretty ridiculous number requiring something closing in on a hundred terabytes? But this actually starts to appear doable I'd think since it would be a static DB. Possibly even comparable to some of the largest static databases handled today? Not for almost any other game such as PLO or 7 stud though.

I've considered that such a database could be used as a super poker calculator for street by street equity or you could get hand match-up stats of strength vs strength for instance. Also a huge benefit for bot analysis I think.

Very interesting idea. I'm only familiar with the most basic concept of hash tables and could see what you mean in theory but I don't have any practical experience with those in practice.

Could you outline a simple example?

I actually had another portion of the method that would involve using hash tables to assign the serial numbers to a data-base that had its hole cards encrypted. Therefore eliminating a link between the SN to the card values a deck contained to order to prevent hole card or future board information from leaking out such as with potential super users.

However, your's sounds like a more elegant overall solution to preventing both card manipulation and card information leaks that could also be verified in a post process.

I think a collaborative effort with many here having much more experience than me could work out a rock solid method that could make it's adaptation as painless as possible. Possibly getting some help from the programmers and probability forums as well though I suspect plenty of crossover members post here.

BTW I would also like to note that the timing for getting this kind of change implemented is pretty much ideal which is why I wanted to bring it up now.

This could be established in future regulation, perhaps allow legislation to pass more easily with fewer worries to weigh in against it. Even poker sites themselves have been asking for added regulation and transparency to trade for legitimate US licensing.

Poker sites are rigged? you cant be serious OP...

This is not a debate over if sites are rigged it's a discussion about putting to rest any future doubts or fears of sites being rigged.

Repairing damaged reputations of the poker world, allowing new players to take part in poker without trepidation. Turning around the 6year decline in the poker economy.

My previous post was a jest OP, on a more serious note I have always found the debate to be a very dubious one in all fairness and find it hard to comprehend how one can assume a site available to use for the public to be rigged, without any relevant body being aware of it, I guess it comes down to newer players being subject to short term variance, often assuming the site they are using blame for the incurrence of short term variance, or what these players would see as constant bad beats. Personally I believe that if many of the players who accuse online poker sites of being rigged had understanding of hand probabilities, outs so on so forth they would have a serious reality check

I have been thinking about a solution to the above problem in the past.
I think using third parties sites/databases wouldn't be feasible in the real world, but the way I see it there are solutions to the problem.

My idea is to have the dealer shuffle the deck, then each player shuffles the deck, thus ensuring a random deck, since a single fair shuffle is enough to make the final deck totally random.

The algorithm isn't too complex:
- each player + the dealer compute a random permutation of the numbers 1..52, ie a "shuffle"
- each player and the dealer send to everyone else a secure hash of the chosen permutation
- each player send to the site the chosen "shuffle" and the site shuffles the deck applying all the shuffles
- at the end of the hand the site reveals to all the players the "shuffles" in unencrypted form for verification by the players (secure hashes will give the required confirmation).

The problem about this approach is, as Rusty pointed out, that it reveals the whole deck and hence everyone's hand, but I think it's possible to extend the above algorithm so that only partial information can be released, thus solving this issue (I have some ideas for that, but it makes the algorithm a lot more difficult and technical, so I won't go into details unless really required... I have even been wondering whether to write a paper about it).

Nonetheless, I think this approach won't totally solve the "rigged" problem. The site is going to know the whole deck anyway before the hand is dealt out, so other forms of cheating are still possible: we guarantee the shuffle is fair, but can't exclude that other players can know our cards or the board before showdown.

I don't think "public acceptance" is a problem here. It's true people won't understand the math details of what's going on, but expert can assure them and regs will be totally fine. Things are already being done behind the scenes with some algorithms that the general public can't understand, while with the voting scenario you had to change their habits from a system they roughly understand to a totally unknown world.
If the regulators forced the use of such a secure system things could only be better.

@Chanty57: rigged rooms have been exposed in the past, the concern is real.

This is the key point. It seems like there are two main types of "rigged":

1. The site is deliberately "rigging" the game, i.e. manipulating the output of cards in order to make certain players (winning players) lose.

2. There is a security hole that allows a player or players to view the contents of a deck before or as its being dealt. A site could sabotage winning players by letting an employee play with inside info or just some random outside person could hack in to take advantage.

So OP does a good and interesting job of addressing 1, but I think he's actually making it worse for 2. Deck information spread across multiple places is more vulnerable. Really I don't see any way of completely solving the problem of deck information. Its always going to be out there somewhere, so I guess the only question is how to secure it in the best way possible. One option might be to take away the ability to create decks and deal cards completely from the site. A government agency or something could do that for a fee, the site would only be responsible for creating the software for the animation and handling all the payment processing, advertising, support, etc. Of course this would leave the deck information in the hands of the govt so I'm sure that leaves a bad taste in the mouths of a lot of online players considering how anti-govt they can be.

Thanks for the replies. There are couple of points that people have brought up that I haven't covered fully as of yet though I made some slight references in my response to Rusty's post.

Which cards to show when validating
I presented a solution to this in a response to Rusty's post.

Securing Card Information

I had alluded to part of the method I had planned to prevent card information from leaking but will go over a more complete solution here.

After the database was generated and hole cards were encrypted, an auditor would assign the SNs to the encrypted DB using a hash table. Therefore the link between SN and card data would be severed. Note that the databases distributed would also be encrypted.

However this doesn't fully cover all of the issues. To do this completely we would need the cards to remain encrypted throughout the dealing process until they ended up at the client where the hole cards would only be revealed to the player.

For this to work we would need to have a separate "Card Client" that would be an overlay to the table and be the only software that could decrypt the cards per regulations. Therefore hole cards would remain private to the user and board cards could not be known prematurely.

The client could display the cards as required but only release the HC data after the action was complete if/when there was a showdown.

This client would actually be a fairly simple program that mostly acted similar to a HUD.

Outstanding issues:
For decryption of the third party databases, I thought that the decryption keys could be released at the end of each hand.

I would need to learn more about encryption techniques to learn how to make this work completely and would appreciate any advice from encryption experts.

Hand histories would be generated such that the action and the cards could be reported seamlessly in the local HH file and the HH file displayed in the HH window, could be done by allowing both clients to append lines to to each HH file in real time revealing only the appropriate information.

We would also need to prevent screen scrapping techniques such that the table client could not read the players hole cards displayed.

Edit to add: I still need some time to look over the suggestions but I'll be busy for the next several hours and hope to go through them more thoroughly later.

I was talking about my approach which I think has many benefits over yours.

I'm not totally sure I get what you are suggesting here, but it looks like we have to trust a third party (the owner of the database) to disclose the information to the right recipient and no one else.
Seems the problem has only been shifted from trusting the room to trusting the public authority, by adding a lot more compelxity in the meanwhile.

I wouldn't be too concerned about the problem of securing the client after infos have been sent over. It's for sure something you should consider, but totally solvable, at least in theory.

Based on the ideas presented here by RustyBrooks, BlackLoter, and NMcNasty, I've made several modifications that are huge improvements and get us much closer to a firm solution. Thanks for the contributions guy's 90% done. I hope to have a working demo soon.

I'll try to outline the entire system as it exists currently.

Isolating Cards to a separate server/client system

Was actually an idea that McNasty started and hopefully I completed to satisfaction.

While the government would definitely take an active role, it would not have any more power to negatively influence the deck than any other party involved.

Dealer Service Provider (DSP)

• A third party company that would be hired by the regulator and paid out of licensing fees.
• It cannot have any other affiliation or relation to the poker site.
• However It may run services for multiple poker sites.
  
• They will work with the regulator to provide the blind Deck SNs as mentioned earlier.
  
• They will be running and maintaining software that includes:

The Dealer_Server

• Handles the card_DB.
• Delivers the cards to Card_clients in real-time but still in it's encrypted form.
  
• Acts as a coordinating hub to the Card_Client and HH_Client.
• Is the only interface with the Poker site server or Table_Server.

The Card_Client

• The main function is to keep hole cards private to the user alone.
• decrypts all cards
• displays all cards or mucks
• Reports board card values in real time.
• Never Reports HC values before action is completed.
• Only Reports HC values after Showdown or Show action is recorded in the HH_Record.
• Responsible for Maintaining the local HH Record that shows up in the HH window as well as the copy on the users HD.
• It exists as an overlay to the Table_Client although does not communicate with it directly.
• At the end of it's 24 hour cycle it outputs all card encryption keys for unlocking encrypted copies of the DB for display.
• Also outputs a report indicating cards as mucked, known, shown, or stub This will provide flexibility on who gets to see what.
  Example:
• I think public not in the hand only sees known cards
• Players in the hand can see Known, shown, and stub cards
  Who would have 100% visibility:
• Any involved in official testing for Full validation or randomness
• investigating cheating
• defend against cheating claims.
  
  Anonomous study with 100% visibility of the deck.
  Stripping decks of SNs and HH's of player names, could allow for anonymous large data studies
• similar to spadebidder.com
• I would personally love to see actual equity changes for all hands as any of these variables change: Pos, Avg Stk, Num Plyrs using a dynamic heat map and a slider.
• If using Truly random data, unused data could be recycled.
  

The HH_Client

• Is the same HH_Window your used to seeing.
• Receives the HH data directly from the Card_Client.
• Responsible for the Player Codes I/O where it prompts for a user code at the start of each table and reports the code to other players via local HH_File when a player leaves the table.

While this seems like a fairly complex change, it's not at all. For the user, there will be almost no visible change other than the addition of Player codes.

Isolating cards and action falls along a very natural line of segregation in terms of the code since they are virtually independent processes from each other with the only exception being merging outputs in the HH_Record.

This new relationship with a DSP will in many ways be very similar with the Poker Sites relationship to database/HUD companies.

While this may seem like an extra burden to regulators. It actually places all features that would be of concern to regulators for keeping the game fair into relatively small and simple programs that can be audited far more easily as opposed to the reams of code required to run the main server/client software and where hidden code could easily go un-noticed.

Also simplicity will keep revision updates infrequent. By comparison weekly or even daily updates we see from the main client software would be very tough for regulators to keep up with.

With control over Cards and Hand histories, the regulator could have more direct control over HH data miners.

Separation of control, enables double blind scenarios which should prevent exploitation of the cards from any party, including the DSP.


Following shows the new dealer process flow:

1. DSP Generates a batch of 2880 shuffled decks.
2. DSP Tests it for randomness.
3. Auditor/Regulator Encrypts the card values creating a double blind process that should sever any link between Deck SN and the value of cards within the deck preventing any knowledge of hole cards or premature knowledge of board cards.
4. Auditor Distributes 2 encrypted copies to third party watch dog groups that will be decrypted and displayed the day after to allow player validation.
5. *At game time, players randomly pick player codes when joining the table
6. Hand Seed values are the sum of all player codes plus the time element that's recorded at the start of each deal.
7. Instead of the sead value determing a random decks SN to deal. Decks are now simply used in sequential order thus saving a lot of headache with SN collisions and over-sized DBs.
8. The seed is instead used in a publicly known PRNG Hash algorithm to re-order each deck. This creates a final deck that is the result of each players own choice of a random number.
   
   Kind of like the idea behind a single player cutting the deck except its more like every player having inter-dependant influence over a complete shuffle.
   
9. It also creates a needed redundant shuffle since There's no guarantee that the first shuffle would have been up to par other than saying it's supposed to be checked for randomness.
10. After a session players will have access to all relevant player codes, time elements, Hash algorythms, and Card database which pre-existed to the actual dealing of the hand. Therefore a manual reproduction of the same hand will validate 0% chance of card manipulation by any party.

*Sections 5-9 were modified to resolve the point I was stuck at with the first post thanks to changes that were based on ideas I picked up from RustyBrooks and BLackLoter with overlaying hashing algorithms.


I'm now working on creating a working model for this process for proof of concept using Excell.

However, while I'm working on that, I still have some questions over whether encryption techniques would work with the system as described. Any recommendations in this area would be greatly appreciated.

I think this is probably solvable with some exiting cryptographic protocols and zero trust (your scheme involves at least trusting a 3rd party card provider)

I suppose if your goal is to prevent even the poker site from knowing the next card, then you'll need some soluation to that problem.

It's probably doable via cryptographic means, actually. I mentioned hashing algorithms earlier. I don't mean "hash maps" by these. "hash maps" are called that because they use hashing algorithms, not the other way around. A "hashing algorithm" is just a means to turn X bits of data into Y bits of data (usually, Y << X) that has some properties such as:
1. Y can not be deduced by X
2. it's not trivial to make Y' such that hash(Y) = X and hash(Y') = X
3. if you change 1 bit of Y, you should expect an average of 1/2 the bits of X to change
there may be some more properties.

The use of a hash is that let's say I have a chunk of data. I don't want to show it to you, yet, but I want to prove that I have it right now. Let's say I'm going to ask you a question, you're going to answer it, and then I'm going to provide my answer to the question afterwards. You'd like to know that I didn't change my answer after hearing yours.

So, I compute the hash of my answer and give it to you. You can't guess my answer by looking at the hash. When it's my turn, I give you my answer and you can compute the hash and compare it to the one I gave you, and see that they're the same. Because of the properties of the hash, it would be nearly impossible for me to have reformulated my answer into another one with the same hash, so you can be relatively assured that that it was the answer I had in mind all the way.


I'd really advise you check out a book such as Bruce Schneir's "Applied Cryptography". It will teach you how to think about these problems and simplify them into means that don't require trust (a fundamental implication in crypto is trust no one)

It's a thick tone (maybe not so bad now - when I bought it, in like 1995, it included the source code to several popular encryption algorithms, I am sure it does not now) but it's fairly readable and it isn't required to read all of it.

Thanks for the info. I'll definitely check it out.

While I did assume you meant Hash Map I had to make some assumptions about how you would generate such a map. As it turns out it sounds a lot like what you described.

I knew a method that could scramble any list of numbers in Excel, added a bit of code so that I could apply my own seed value (determined by player codes + time) and essentially used it to scramble the deck in a deterministic fashion.

This is the code using VBA:

Which created this list of 52 random numbers:

0.816836417, 0.227755547, 0.286929309, 0.171114564, 0.520939171, 0.901824236, 0.155592382, 0.142517924, 0.124551356, 0.787520885, 0.658902824, 0.401385427, 0.291552365, 0.705707312, 0.896775186, 0.960473418, 0.046173155, 0.396190643, 0.212288082, 0.10304606, 0.601121247, 0.033348322, 0.644809186, 0.023500323, 0.435705721, 0.991753101, 0.633120239, 0.717990994, 0.623962224, 0.861798048, 0.968542039, 0.125055671, 0.41277796, 0.715321541, 0.998059452, 0.516239762, 0.050016701, 0.621232271, 0.077446401, 0.136721492, 0.862643778, 0.411134243, 0.274390876, 0.095936894, 0.584851086, 0.694951773, 0.321619928, 0.508204818, 0.936182082, 0.126554489, 0.820024669, 0.883351922

I then applied an Excel Trick created by Dan Mayoh. Here's a video which describes it pretty well.

http://www.youtube.com/watch?v=HLEF6DeBsH8

which resulted in a list of 52 unique randomly ordered integers:

26, 34, 46, 3, 7, 19, 30, 4, 41, 33, 36, 16, 45, 39, 31, 25, 28, 32, 24, 8, 52, 21, 51, 22, 44, 23, 48, 35, 13, 9, 15, 43, 12, 29, 1, 38, 20, 2, 10, 6, 37, 5, 11, 49, 47, 42, 50, 27, 14, 40, 18, 17

And this I used as the hash map to reorder the deck in a deterministic manor and could be repeated by starting with the same seed value.

Notice that while I do agree that my original plan would require some amount of initial trust in whomever generated the original set of data. My assumption was that since the data would be static, we could always back test it for randomness after it was used.

However, this method actually takes care of that by essentially reshuffling the deck based on the unique seed value we get for each table using player codes + time.

Also I agree that to hide the values we could use encryption which I still need to verify would work using my method.

Basically I use a double blind method where a third party generates the random DB and encrypts the data before a regulator or auditor hired by the regulatory body would apply a similar technique which I just described except for 2,880 serial numbers to randomly assign those SNs to decks that had encrypted data. This was the double blind method I talked about since neither the regulator or the originator of the Random DB could know anything about the data for a given serial number at that point.

Since the data is now unknown, I felt that just using the decks in the order of the SNs would be safe and then of course, the player code shuffle becomes pretty important at this point since this is the shuffle that players can guarantee actually happened.

So with all of the steps, we start with the source of randomized decks.
Encrypt the data
Then scramble the order of the decks with a double blind method and apply SNs
Then use the decks in order but apply one more shuffle based on player codes. I also really like the fact that the players who's are the only opinions that matter actually apply the last scramble themselves using player codes.

So the deck is random, the card values are unknown, and it can all be recreated and validated against static pre-session data. This achieves all of the original goals up to a point.

There is still one weak spot which is in trusting the card client.

Note that to keep the hole cards unknown during a hand it did involve isolating a special Hole Card client apart from the poker sites client. Also having it maintained by an outsourced third party hired and paid by the regulator. At the very least it's harder to see motive for a third party that got paid in such a manor which is a pretty big factor in itself.

I did mentioned that local HH files contain your hole card information. I thought that by keeping the file opened it could prevent other software from reading the HH file but there are still ways around that. I suppose it could just not write the current hand to the file until after the action is over.

Also it would need to prevent screenscraping to read your cards that way. And also protect the way it generates the card image. I don't think you want to use a single image per card for instance or some malicious program could rename those files changing what cards you would see. Instead I believe you'd be safer by layering images onto blank cards, perhaps even transmitting the last bit of image data that finally defines the card value. I imagine this has all been encorporated into the software already since this kind of threat wouldn't be new.

My knowledge in software security is pretty limited. Hopefully some experts in the field could contribute.

I think that we've at least limited potential issues to a very small area so I'm still hopeful that we could plug all the leaks with the right experts helping us out.

I did provide a simple algorithm which achieves safe shuffling under the "trust no one" and "no third parties" constraints, in my first post in the thread.
I can also extend it to achieve the "only reveal cards which should be revealed at the end of the hand" constraint.

I know of a way to extend the algorithm so that the server can't know flop, turn and river before they are dealt out.
I don't know of a way to furtherly extend it so that only the clients know the hole cards.

If the clients were dealt cards from different decks there is a way to limit the knowledge of the cards only to the legitimate player (for example if they were throwing dice rather than drawing cards from a single deck).

It gets very difficult when you have to figure out a way to limit the knowledge of the hole cards to every owner. What's difficult is that there is a joint probability function, so basically everyone has some insight into the state of the whole game.
The problem arising is to share some information and be able to limit it to what's strictly necessary.
I believe it's probably possible to figure out an algorithm achieving this result too, but not trivial at all.

Even with such an algorithm in place there would still be some concern.
A lesser concern is the "securing the client" issue: although it is an issue, it's basically a separate problem and one which can be dealt with.
A bigger concern is the "disconnection problem". If a client disconnects and all the previous constraints are satisfied, it means it won't be possible to keep dealing the community cards nor to disclose the cards of the disconnected client when a showdown is required.

My hint is not to get concerned about algorithms to generate random numbers, secure hashing algorithms, encryption algorithms (private and public key ones).
It will be more than enough to know such algorithms exist and are reliable.
You should only know what they achieve and may then use those tools into creating your own algorithm to solve the problem.

You can't test a single sample for randomness, and it won't be so useful to perform statistical analysis.
What should be done is to create an algorithm ensuring randomness under the "trust no one" contstraint.
My algorithm achieves this constraint, check it out to understand how it does.
Your algorithm does too if the random input from the players is used well enough. In the end you will end to the point where "players don't care if the deck provided by the third party is not random at all" and thus to "we don't need a third party at all, we can just use a non random, ordered deck to start with". At this point you will probably converge to my algorithm though (or a variant), so my suggestion is to check it out.

You can use encryption to tell someone something you know without anyone else being able to eavesdrop it. But how can you use it so that the player will know shomething that you don't either know, while still having some information about it? This is basically the problem I'm not able to fully solve at the moment.

It looks to me you don't know what encryption does, and thus use it like a magical recipe to achieve goals it can't achieve.
What encryption does, is: it allows 2 parties to communicate safely. So it's basically a requirement of various steps of the process, but I don't see the need to address it explicitly at the moment.

This is not really a weak point, it can be practically difficult but it's not a theoretical concern, I again suggest to just ignore it at the moment.

It still breaks the "trust no one" goal. It also adds another party to communicate with and a lot of complexity to the protocols.
I play in Italy where we have such a third party, used only to make sure taxes are paid in full. It's a pretty simple feature but it creates a lot of problems.
And if you ask me, I trust the room a lot more than I trust this external regulator.

It seems the sites and 3rd parties deal whatever cards they want and before space time we are not going to have a rng that we can trust?

Tracking w eye and not has already proven bot, collusion, superuser cases, but not a single mass riggie rng case happening has been proven since 1998 or so.

If there is a riggie, its getting subtle enough before space time that it probably cant be spotted. So, any efforts to other than space time will make things worse for the eye, and the only thing one can hope, it would lead to some trusted 3rd party rng developments, ran by fbi space research department and any cards can be back checked from them.

I really hope that's a parody of some kind

lol not rigged. play live beats are just as bad.

This thread does not need to derail into whether or not online poker is rigged. Thanks in advance.

http://en.wikipedia.org/wiki/Mental_poker

"One possible algorithm for shuffling cards without the use of a trusted third party is to use a commutative encryption scheme. A commutative scheme means that if some data is encrypted more than once, the order in which you decrypt this data will not matter."

An algorithm for shuffling cards using commutative encryption would be as follows:

1. Alice and Bob agree on a certain "deck" of cards. In practice, this means they agree on a set of numbers or other data such that each element of the set represents a card.
2. Alice picks an encryption key A and uses this to encrypt each card of the deck.
3. Alice shuffles the cards.
4. Alice passes the encrypted and shuffled deck to Bob. With the encryption in place, Bob cannot know which card is which.
5. Bob picks an encryption key B and uses this to encrypt each card of the encrypted and shuffled deck.
6. Bob shuffles the deck.
7. Bob passes the double encrypted and shuffled deck back to Alice.
8. Alice decrypts each card using her key A. This still leaves Bob's encryption in place though so she cannot know which card is which.
9. Alice picks one encryption key for each card (A1, A2, etc.) and encrypts them individually.
10. Alice passes the deck to Bob.
11. Bob decrypts each card using his key B. This still leaves Alice's individual encryption in place though so he cannot know which card is which.
12. Bob picks one encryption key for each card (B1, B2, etc.) and encrypts them individually.
13. Bob passes the deck back to Alice.
14. Alice publishes the deck for everyone playing (in this case only Alice and Bob).

The deck is now shuffled.

This algorithm may be expanded for an arbitrary number of players."

Many similar schemes have been proposed (see some links in the wiki page), and some even coded and used in other games online. There was a paper or article published somewhere a few years ago on using such a scheme for commercial online poker, but I can't find it now. Pretty sure there's an old thread on here discussing it.

Very nice, I didn't know about commutative encryption schemes and that's exactly what's needed to isolate information.

From one old guy to another, who says we can't learn a new trick?

Excellent reference! Thanks for bringing it up.

Just so it's easier for me to understand I've rewritten the Commutative encryption scheme in my own words.

I've also included a last step not included in the quote but readers can reference the link to read it as originally described if needed. It basically describes how each player finally decrypts their hand.

To differentiate it from my encryption scheme, the method here is called a:

commutative encryption scheme.

From now on I refer to my method as a

community encryption scheme.

I've assigned these labels for easier future reference:

Deck Key Encryption (DK/DKE): 1 key to encrypt 52 cards individually.

Card Key Encryption (CK/CKE): 52 keys to encrypt 52 cards.

1. The deck goes around the table with each player adding their own Deck Key Encryption followed by a shuffle.
2. It goes around again with each player removing their DKE and applying a Card Key Encryption and the hand is dealt.
3. After receiving their cards, players distribute the correct Card Keys to each other so that each can then decrypt their own hands. It's easier to think of it as every player dealing their keys out in the same pattern as the cards. So in a 10 handed game each player removes 10 layers of encryption with 20 keys on 2 cards for Hold'em.
4. Also I'm adding that while it wasn't mentioned, before the next deal the players would need to regenerate new keys to replace those that were passed around and exposed to the other players.

After applying it to a full ring game, I think I should point out that these methods seem to be intended for small games of 2 or 3 players where not so many keys would need to be regenerated. It was hinted at that this was a solution for smaller games while trusting players could allow some easier versions to work.

As described in the Wikipedia article, the commutative based scheme is to cumbersome to be practical in many cases. Since the writing seems to be several years old, I'd be interested if anything new has developed since.

However, despite these apparent issues, I believe it's provided me with all the missing pieces for a major breakthrough.

By combining my community encryption technique and the commutative technique. I think we have all of the components to make a perfect hybrid technique. Possibly even achieving the theoretical limit on efficiency.

Break down the problem into 2 components of card position and card value. We use shuffles and back validation as proof against possible card position manipulation and encryption to guard against card information exploitation.

However we can see encryption and shuffles as actually being two viewpoints of the same thing. Let me explain. Think of the cards "values" not as rank and suit but as numbers from 1-52 which makes understanding this a little easier.

Let's say I use a PRNG with a seed value to shuffle the deck and change all the relative positions of the cards for all practical purposes, I did a pretty decent shuffle of the cards to any observer.

However, what if I changed my point of view and said I'm not shuffling the cards, I'm encrypting the data and it's an encryption key and not a seed value. So now you look at it again and you see all the values did indeed change and someone seeing it for the first time would not be able to know the values without the encryption key to change them back.

So despite using the process being exactly the same it's only the point of view that makes it one or the other. In fact it's even odder than that since we can just apply it twice and say it's been encrypted and shuffled and since they are interdependent events it even with regards to the order even the point of view on which one I called a shuffle and which one I called an encryption.

Just something to think about.

The point is that we have a community encryption technique already established. But it gets even better. Each player has their own key for a more personalized encryption as well. But we've already seen that personal encryption can be a very cumbersome process. Except it gets even better when we start looking at the case of position.

For Holde'm, at least, card position is predetermined. Once the deck is shuffled and ready to deal, it's also set and no future action will change what the flop, turn or river would be.

Example:
10 handed game, before the deal, we know that:
SB gets the 1st & 11th cards in the deck.
BB gets the 2nd & 12th
.
.
.
Button gets the 10th & 20th
with no burns needed
Flop. Turn, River are cards 21-25

So, what if we used this information to tailor our encryption technique specifically for where the cards will end up? Starting to get the picture?

Lets back up a bit and say a peer to peer connection between clients in order of the seating has been established in a ring configuration. All data can only pass to the left.

Each client holds the individual players key respectively and know other party has access to it. Furthermore, we can distribute the Combined community key without revealing any personal key information.

The small blind generates a random number independent of anything other than it should be significantly large compared to a personal key. It adds the SB key and passes it to the BB which adds the BB key and so on until it gets all the way back to the SB which can then subtract that original random number.

Now each client holds one personal key for the player and a community key for the table. Perfect. No other client or server has even needed to get involved yet.



Back to live play: The encrypted deck gets shuffled by the dealer client using the community key. Since the deck had already been encrypted, the dealer cannot know the cards value in any position.

The dealer encrypts cards 21-52 with the community key,encrypts cards 10 & 20 with the player key and passes it to the SB client which adds an encryption for cards 1 & 11, the BB encrypts 2 & 12 etc.

Once passed around, the decks now shuffled and fully encrypted by the players. The deck is passed back out to the dealer service provider. The previous encryption is removed and the server provider cannot have any information on the newly shuffled and encrypted deck. In fact no one can have any information on it which is perfect.

As the cards get dealt, each card that's received can be decrypted by each players personal player key. Also when the board comes out each player can decrypt the board cards which is Perfect.

If there's a showdown, the player's clients then passes those un-encrypted cards values to the other clients where the only information about them came from the play itself and nothing more which is perfect.

Now assuming the client is not rigged, we've pretty much covered all other leaks.

Also we can even remove much of the pre-process which has become redundant during this process.

So What about other games such as Stud where the deck is not set? I may have a solution for that but it will take a little more time to work through it.

From one old guy to another, who says we can't learn a new trick?

Excellent reference! Thanks for bringing it up.

Just so it's easier for me to understand I've rewritten the Commutative encryption scheme in my own words.

I've also included a last step not included in the quote but readers can reference the link to read it as originally described if needed. It basically describes how each player finally decrypts their hand.

To differentiate it from my encryption scheme, the method here is called a:

commutative encryption scheme.

From now on I refer to my method as a

community encryption scheme.

I've assigned these labels for easier future reference:

Deck Key Encryption (DK/DKE): 1 key to encrypt 52 cards individually.

Card Key Encryption (CK/CKE): 52 keys to encrypt 52 cards.

1. The deck goes around the table with each player adding their own Deck Key Encryption followed by a shuffle.
2. It goes around again with each player removing their DKE and applying a Card Key Encryption and the hand is dealt.
3. After receiving their cards, players distribute the correct Card Keys to each other so that each can then decrypt their own hands. It's easier to think of it as every player dealing their keys out in the same pattern as the cards. So in a 10 handed game each player removes 10 layers of encryption with 20 keys on 2 cards for Hold'em.
4. Also I'm adding that while it wasn't mentioned, before the next deal the players would need to regenerate new keys to replace those that were passed around and exposed to the other players.

After applying it to a full ring game, I think I should point out that these methods seem to be intended for small games of 2 or 3 players where not so many keys would need to be regenerated. It was hinted at that this was a solution for smaller games while trusting players could allow some easier versions to work.

As described in the Wikipedia article, the commutative based scheme is to cumbersome to be practical in many cases. Since the writing seems to be several years old, I'd be interested if anything new has developed since.

However, despite these apparent issues, I believe it's provided me with all the missing pieces for a major breakthrough.

By combining my community encryption technique and the commutative technique. I think we have all of the components to make a perfect hybrid technique. Possibly even achieving the theoretical limit on efficiency.

Break down the problem into 2 components of card position and card value. We use shuffles and back validation as proof against possible card position manipulation and encryption to guard against card information exploitation.

However we can see encryption and shuffles as actually being two viewpoints of the same thing. Let me explain. Think of the cards "values" not as rank and suit but as numbers from 1-52 which makes understanding this a little easier.

Let's say I use a PRNG with a seed value to shuffle the deck and change all the relative positions of the cards for all practical purposes, I did a pretty decent shuffle of the cards to any observer.

However, what if I changed my point of view and said I'm not shuffling the cards, I'm encrypting the data and it's an encryption key and not a seed value. So now you look at it again and you see all the values did indeed change and someone seeing it for the first time would not be able to know the values without the encryption key to change them back.

So despite using the process being exactly the same it's only the point of view that makes it one or the other. In fact it's even odder than that since we can just apply it twice and say it's been encrypted and shuffled and since they are interdependent events it even with regards to the order even the point of view on which one I called a shuffle and which one I called an encryption.

Just something to think about.

The point is that we have a community encryption technique already established. But it gets even better. Each player has their own key for a more personalized encryption as well. But we've already seen that personal encryption can be a very cumbersome process. Except it gets even better when we start looking at the case of position.

For Holde'm, at least, card position is predetermined. Once the deck is shuffled and ready to deal, it's also set and no future action will change what the flop, turn or river would be.

Example:
10 handed game, before the deal, we know that:
SB gets the 1st & 11th cards in the deck.
BB gets the 2nd & 12th
.
.
.
Button gets the 10th & 20th
with no burns needed
Flop. Turn, River are cards 21-25

So, what if we used this information to tailor our encryption technique specifically for where the cards will end up? Starting to get the picture?

Lets back up a bit and say a peer to peer connection between clients in order of the seating has been established in a ring configuration. All data can only pass to the left.

Each client holds the individual players key respectively and know other party has access to it. Furthermore, we can distribute the Combined community key without revealing any personal key information.

The small blind generates a random number independent of anything other than it should be significantly large compared to a personal key. It adds the SB key and passes it to the BB which adds the BB key and so on until it gets all the way back to the SB which can then subtract that original random number.

Now each client holds one personal key for the player and a community key for the table. Perfect. No other client or server has even needed to get involved yet.



Back to live play: The encrypted deck gets shuffled by the dealer client using the community key. Since the deck had already been encrypted, the dealer cannot know the cards value in any position.

The dealer encrypts cards 21-52 with the community key,encrypts cards 10 & 20 with the player key and passes it to the SB client which adds an encryption for cards 1 & 11, the BB encrypts 2 & 12 etc.

Once passed around, the decks now shuffled and fully encrypted by the players. The deck is passed back out to the dealer service provider. The previous encryption is removed and the server provider cannot have any information on the newly shuffled and encrypted deck. In fact no one can have any information on it which is perfect.

As the cards get dealt, each card that's received can be decrypted by each players personal player key. Also when the board comes out each player can decrypt the board cards which is Perfect.

If there's a showdown, the player's clients then passes those un-encrypted cards values to the other clients where the only information about them came from the play itself and nothing more which is perfect.

Now assuming the client is not rigged, we've pretty much covered all other leaks.

Also we can even remove much of the pre-process which has become redundant during this process.

So What about other games such as Stud where the deck is not set? I may have a solution for that but it will take a little more time to work through it.

Since we can now make this anti rigging scheme secure up to having to trust a card client which should be a relatively simple piece of code, I'm thinking that we could create transparency for this client by writing it in a text script such as AHK so that users could verify that it's only doing what it's supposed to do.

Or give the user an uncompiled version that the user may copy and compile themselves to verify the card client.

However, then the risk becomes that of a user rigging the code.

could a hashing code be run on a compiled file to verify no modifications were made? and if a server could block a client based on this?

Comparing hashes for free, open source code is quite common to verify authenticity. I think all reputable Linux distros come with a hash (MD5 or SHA1 I believe) I don't know how the hash is computed. Trucrypt does as well.

I don't know about this part. There is probably a more effective way to guarantee the authenticity of the client to the server but I don't know what it is.