My system has been up and down last couple of days, and what with this and the small downtime on toad.com I'm not sure if my message got through on Karl's idea to use blackjack as an example crypto based card game. First I'll mention that I was browsing rec.gambling this morning and I saw several references to poker games being played over IRC. They had an init file posted which defined macros so you could say "/raise", "/fold", etc. This might be something which could be incorporated into a good crypto-strong version. (A corollary would be to hack the existing code so you could win every time if possible. I believe they are relying on a trusted server at a well-known host.) The point I had made earlier about blackjack was that Karl's idea is good if there is just one player and one dealer. The dealer shuffles and publishes a hash of the deck so that he is commited to it. Then they play through the deck. At the end the player can confirm that the hash of the played cards in sequence matches that originally published. Since the dealer has no discretion in blackjack this works well and it is much simpler than the more general protocols. The one problem I saw was that if there were more than one player, the dealer and one or more players could collude to cheat the other players. The dealer could tell his players what the upcoming cards were, and they could hit or stand in such a way as to hurt the other players. The sol- ution I proposed was a little bit complicated, but still quite a bit simpler than the full-generality card-playing protocols, I think. You just have the players and dealer cooperatively choose the next card to be played via a joint coin-flipping-type algorithm. By using the English version of blackjack, in which all cards can be dealt face-up, everyone learns each new card at once and there is no opportunity for any players to know what the cards will be ahead of time. Of course, blackjack is not nearly as popular as poker, so perhaps a more general implementation is desirable for this reason. Hal