Card Playing Protocol
Oh, GREAT! Tim says (roughly): "Go for it, too bad you are doomed to lose interest shortly." Geeze, I hate people who make generalizations which are, well, likely to be borne out yet one more time. (I *hate* that!) <Mutter grumble hrumph errrrrrah, phooy!> So I am either supposed to put my tail between my legs now, or take this as a challenge to "Follow through this time.", or let it soon die quietly and hope Tim takes mercy and doesn't rub my nose in it. Grrr. I *hate* reality. So here is where I am: 1) I am wondering whether a "digital deck of cards" is a good choice. 2) If it is, I am wondering how the protocol would roughly be framed (Fundamental card operations, etc.), with an eye towards what the cryptographic protocols can offer. 3) Then, if things make sense, appear tractable, and (drum roll) I haven't gone onto fresher blue-sky ideas, I figure out how to start building the damn thing. 4) And if I ever get to building it I will start first with the little pieces (the cryptographic fragments) which might be useful individually when I lose interest in building the larger beast. I assume that I will have to do real work at each of these stages--though I welcome any help. Both now when the talk is still cheap and later when the bits hit the disk. So far I am at step #1, nudging towards portions of step #2. I refuse to be shamed about abandoning step #3 until I have at least embarked on it. (Then you can make fun of me.) Just producing a complete RFC-quality protocol would be something not to be sniffed at. In fact, I am prepared to stop there and *still* feel smug. (So there!) As for getting people to want to use this digital deck of cards, I rely on my passion for good user interface design combined with the continuing popularity of card games. (And people's continued interest in playing games with other people rather than just computers.) So I am currently at step #. Is the Card Playing Protocol a good choice for being: 1) cryptographically interesting 2) tractable 3) "harmless" 4) appealing to users? Comments? (You too Tim.) And Tim, don't worry about my eyes becoming glazed over with images of Donald Trump. I don't like The Donald. Gambling is boring. (Besides, generalized transactions are far more appealing to a megalomaniacal fool like me. How CPP applies remains for me to understand...) -kb, the Kent who is going to be Cometing tomorrow, handy annual open house at JPL this weekend, etc. -- Kent Borg +1 (617) 776-6899 kentborg@world.std.com kentborg@aol.com Proud to claim 32:00 hours of TV viewing so far in 1994!
1) I am wondering whether a "digital deck of cards" is a good choice. Premature abstraction is a severe problem if it happens to you. Read some of the literature to get an idea of the techniques before you pick an abstraction. Your remarks about knowledge models for an abstraction proposal of "a table with stacks of cards" seem on target. Most card games require a random permutation, mutually trusted to be random, which can be revealed one card at a time. That permutation need not be generated in advance. Games like Magic--The Gathering in which each player shuffles their own deck, are easier to implement and only require bit committment. The revealing of cards cannot be global, since at the beginning each player sees only their own cards. The revealing of cards should require that the cooperation of each player that sees the cards, and possibly some others. Time to read crypto. Eric
Kent Borg writes:
Tim says (roughly): "Go for it, too bad you are doomed to lose interest shortly."
Geeze, I hate people who make generalizations which are, well, likely to be borne out yet one more time. (I *hate* that!)
No, I think it's a fine project, certainly more useful in the long run than another PGP shell. But also more complicated, if done right. (Done right = reusable building blocks for the various needed primitives.)
So I am either supposed to put my tail between my legs now, or take this as a challenge to "Follow through this time.", or let it soon die quietly and hope Tim takes mercy and doesn't rub my nose in it.
Grrr. I *hate* reality.
Glad you are taking my comments in the spirit in which they were given. There are some pretty good reasons many of the ideas excitedly discussed here never reach fruition: 1. No time. Most people have full-time jobs doing other things. 2. No funding sources to _force_ people to complete things they've already been paid for. 3. No group of co-workers to chat with, to reignite interest, to exert peer pressure to finish. It's just _so easy_ to let a project kind of s-l-i-d-e a-w-a-y...
So here is where I am:
1) I am wondering whether a "digital deck of cards" is a good choice.
Read up on the "playing cards by telephone" papers of the early to mid-80s. Maybe implementing just one of the sets of ideas would give your further insights.
2) If it is, I am wondering how the protocol would roughly be framed (Fundamental card operations, etc.), with an eye towards what the cryptographic protocols can offer.
That's the central issue.
3) Then, if things make sense, appear tractable, and (drum roll) I haven't gone onto fresher blue-sky ideas, I figure out how to start building the damn thing.
4) And if I ever get to building it I will start first with the little pieces (the cryptographic fragments) which might be useful individually when I lose interest in building the larger beast.
I assume that I will have to do real work at each of these stages--though I welcome any help. Both now when the talk is still cheap and later when the bits hit the disk.
Lots of work. Remember, the mathematicians and computer people who did these papers did not bother to build them into computer code, though some of them surely could have if it were easy. (Chaum's people built a running simulation--and crypto simulation is what we're talking about here--of digital cash, but the version I saw was unusable by other programs. That is, it was a "user at the console" sort of thing, not a tool or class library or even a function call.) What's lacking in crypto is a reasonable "framework" for these concepts and functions to live it.
As for getting people to want to use this digital deck of cards, I rely on my passion for good user interface design combined with the continuing popularity of card games. (And people's continued interest in playing games with other people rather than just computers.)
Good user interface is probably the wrong thing to be thinking about now, if the goal is wide use. Think "client-server" (or choose your own paradigm). The building blocks are more important than a snazzy Windows or Mac interface.
So I am currently at step #. Is the Card Playing Protocol a good choice for being:
1) cryptographically interesting
Yes,
2) tractable
Unknown.
3) "harmless"
Not a real issue.
4) appealing to users?
For researchers, it would be interesting to have the set of abstractions reified into running code. This is a longstanding interest of many of us, and was one of the motivations two years ago to form the Cypherpunks group. Eric and I figured it was high time to take the various theoretical abstractions and implement them in code; we hoped that a bunch of people would generate "Pretty Good Digital Money," "Pretty Good DC-Nets," etc. So far, it's been slow. (And some actual deployments, such as Digital Money, have faltered for other reasons. Kent should look at MM and why it isn't in wider use and try to learn some lessons for a gambling scheme.)
Comments? (You too Tim.)
See above. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."
participants (3)
-
hughes@ah.com -
kentborg@world.std.com -
tcmay@netcom.com