Cypherpunk Criminal
Christian, I finally received my tees in the mail yesterday. Very, very cool. The .gifs certainly didn't do them justice. Thanks again, _______________________________________________________________________________ Paul Ferguson US Sprint Enterprise Internet Engineering tel: 703.904.2437 Herndon, Virginia USA internet: paul@hawk.sprintmrn.com
This may set a new record for me in putting seemingly unrelated topics into a single post!. But upon getting home from a technial conference last night (which had Neil Young as a participant) and getting ready for a Pink Floyd concert in distant Oakland, I found 210 e-mail messages on my machine, most of them Cypherpunks. No way can I digest them soon (and Netcom compressed them before I could download them with Eudora....ah, the wonders of these systems). So, without furhter explanation, a move from "Cypherpunk Criminal" t-shirts to Neil Young to capability-based systems to enviroments for developing protocols:
Christian,
I finally received my tees in the mail yesterday.
Very, very cool. The .gifs certainly didn't do them justice.
Thanks again,
_______________________________________________________________________________ Paul Ferguson
I got a Cypherpunk Criminal t-shirt, from Curtis Frye (thanks!), as I had neglected to get my order to Christian in on time. I agree that it's a great t-shirt! I wore it at the Asilomar Microcomputer Workshop, where it got a lot of interest. Ironically, most of the interest was in the number on the back, not the giant lettering on the front...I guess it proves that people talk behind my back. Neil Young, the music guy (and one of my all-time favorites), was at the conference to talk about his joint venture with Lionel Trains (*), and he smiled when he read what was on the t-shirt. (*) Neil Young has a 600-acre ranch in the Santa Cruz Mountains and a huge model train setup, which he uses with his disabled son. He's very supportive of technology for the handicapped, and wanted a "tetherless" radio control for train setups. For the past 10 years he's funded efforts, most of which were derailed by technical problems (like sending logic signal in an extremely RF-noisy environment). The problem is making a system backwards-campatible with the installed base of Lionel trains (and others that use the same power system, the same "blue sparks" (lots of RF!), etc. He recently worked with some guys he met through the Asilomar conference, including our own Bruce Koball, and great progress was made. After achieving some success, including a "manufacturable" system, he met with the President of Lionel, who got over his initial skepticism and became a supporter. A 50/50 partnership called "LionTech" exists and is set to roll out a complete system of backwards-compatible controllers and whatnot, this coming October. (New engines, with sound effects, including digitally recorded-and-compressed railroad sounds, are needed, but old tracks, old transformers, old cars, etc., will still work.) It looks pretty exciting, and I suspect it'll sell well. (I suggested thy work with Fry's Electronics, the mega-electronics chain in the Bay Area, and Neil thought this was a great idea, as Fry's has huge amounts of floor space for a good demo setup.) Neil was also very much interested in other kinds of tech (no, I didn't hit him up to fund digital banks!) and it was a real pleasure to be able to talk to him in such a small setting....the 100 or so attendees at Asilomar were in the sharpest possible contrast with seeing Pink Floyd last night in the Oakland Stadium! I hope this isn't too far "off the track," so to speak, for this group. I did give a 25-minute talk on "Implications of Cryptography," which generated some good discussion. I also cemented some thoughts in discussion with Bernard Peuto and Ted Kaehler about the need for a deeper analysis of the old computer science work on "mutually suspicious cooperating agents," which was predicted to be a Big Thing for computer science (along with objects, segmented logical address spaces, and several other such Good Ideas), but which faded out when C and flat, Unix-style address spaces came to the fore. Some of these failed ideas could finally achieve more prominence where they are actually needed: not built into high-volume mass-market microprocessors (where the failures like the i432 occurred), but used instead in digital money, reputation-based systems, etc. (The academic cryptographers are mostly oblivious, it seems to me, to the work done in operating systems and agoric systems.) The work of Norm Hardy, Dean Tribble, discussed here a couple of times--but always useful to do again--immediately comes to mind. Food for thought. I'm wondering if a project to implement a kind of "Digital Money World," perhaps in SmalltalkAgents, wouldn't be an interesting project. (Many will probably tell me that a collection of Perl scripts would be more "portable" and more useful to the current Unixcentric community....something I'd like to see more discussion of.) Exciting times. --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."
From: tcmay@netcom.com (Timothy C. May) Subject: T-Shirts, Neil Young, Asilomar, and Smalltalk Date: Sat, 23 Apr 1994 13:13:00 -0700 (PDT) Thanks for the great message. I hope I don't start (too much of) a flame war about these religious issues... ... I did give a 25-minute talk on "Implications of Cryptography," which generated some good discussion. I also cemented some thoughts in discussion with Bernard Peuto and Ted Kaehler about the need for a deeper analysis of the old computer science work on "mutually suspicious cooperating agents," which was predicted to be a Big Thing for computer science (along with objects, segmented logical address spaces, and several other such Good Ideas), but which faded out when C and flat, Unix-style address spaces came to the fore. You might want to check out research about "the Byzantine Generals problem", e.g. in ACM's TOPLAS, including (I believe) stuff about synchronizing distributed mutually-suspicious clocks. As I understand it, many these problems have been generally solved in theory, and are just waiting for demand and resources to be put in practice. There is room for more work, of course. Objects are Great; C++ (using objects, in I believe the way you mean) is clearly the language of choice for the virtually the entire (commercial) programming industry. At least this is for software; if you are talking about hardware support (e.g. segmented address spaces, such as the i432) this was always dubious, because in general it is always better (when possible and adequately efficient) to do something at "compile time" than "run time" (for example, proving that resources are protected, by ensuring that given protocols are followed). So I think Objects are a Good Idea, but I think Segmented Logical Address Spaces are in principal Less Good (within reason) than a Single Large Address Space (equivalent in size, within reason) with compile-time "proofs" of non-interference. Of course, multiple process address spaces also absorb the functionality provided by Segmented Logical Address Spaces, and so the Client-Server model now being hyped immoderately is sort of an implementation of the Same Thing. ... Food for thought. I'm wondering if a project to implement a kind of "Digital Money World," perhaps in SmalltalkAgents, wouldn't be an interesting project. (Many will probably tell me that a collection of Perl scripts would be more "portable" and more useful to the current Unixcentric community....something I'd like to see more discussion of.) I suspect the framework of choice would be some sort of MOO or MUD. Of course, once it hit production status, then transliteration into Perl install scripts would be appropriate. Exciting times. You bet -- it sure is interesting to be alive in these "latter days". As his ex-Prince-ness has said: "We're gonna party like it's 1999". Of course, we'd better get strong crypto distributed before the Second Coming -- you think the current US government is involved in a power grab, you just wait!!! This new government will really know how to take care of non-conformists -- Waco is nothing compared to what they are planning (read: fiery brimstone)... I wonder if Jesus can create a number so large he can't factor it? --Tim May Pardon my excursion into various religious topics -- arguably this list is also about religion ("religion is what you do" -- "cypherpunks write code" -- belief that strong crypto should be widely distributed is certainly a religious tenet for some on this list). I hope I haven't offended anybody important... Important UnSeminated Encouragement of this DisInformation Alteration is Distributed. -- dat@ebt.com (David Taffs)
David Taffs has some very interesting points, which largely I am in agreement with:
You might want to check out research about "the Byzantine Generals problem", e.g. in ACM's TOPLAS, including (I believe) stuff about synchronizing distributed mutually-suspicious clocks. As I understand it, many these problems have been generally solved in theory, and are just waiting for demand and resources to be put in practice. There is room for more work, of course.
Thanks for the ref. My feeling is that the work on mutually suspicious cooperating agents was "ahead of its time." This work was started in the 60s, and then the model for compuation shifted from many users, many program on a single machine to one user-one machine (for the most part), and the flat address/RISC/C model "worked." (I'm not saying these are all the same thing, but they're usually found together.) With networks, and especially with heterogeneous mixes of agents executing complicated protocols (a la digital cash), the time may be ripe to reopen some of these issues. Chaum took the "Dining Philosophers" problem (deadlock) and turned it into the "Dining Cryptographers" problem (the full text of the paper in in the soda.berkeley.edu archives, pub/cypherpunks). And "Byzantine Agreement" (is this the same thing as Byzantine Generals?) shows up, I recall, in some crypto papers.
Objects are Great; C++ (using objects, in I believe the way you mean) is clearly the language of choice for the virtually the entire
Yes, of course this is what I meant. That's why I mentioned the Smalltalk approach. (I won't get into issues of performance of C++ over Smalltalk and Lisp systems...my contention is that there's a vast amount of computer power out there and a (relative) shortage of good programmers and their time, and that this implies that only truly time-critical things or many-times-replicated programs warrant writing in lower--level languages. A religious point, no doubt.)
So I think Objects are a Good Idea, but I think Segmented Logical Address Spaces are in principal Less Good (within reason) than a Single Large Address Space (equivalent in size, within reason) with compile-time "proofs" of non-interference.
Indeed, and this was the Great Lesson of the i432 and other capability-based machines, as well as the too-small segments of the 286. (The 486 and Pentium still have segments, as everyone knows, but they are much larger....in fact, I am told that most folks set the segment to the max and forget about it after that.) Ironically, the power of our distributed crypto systems (many machines, many users, many remailers, etc.) is that they are "cryptographically segmented," to coin a term. That is, the various machines are logically segmented, with code only running locally and all communication done via the various comm protocols. This is the strenght of these systems, that some spaces are "private."
Food for thought. I'm wondering if a project to implement a kind of "Digital Money World," perhaps in SmalltalkAgents, wouldn't be an interesting project. (Many will probably tell me that a collection of Perl scripts would be more "portable" and more useful to the current Unixcentric community....something I'd like to see more discussion of.)
I suspect the framework of choice would be some sort of MOO or MUD. Of course, once it hit production status, then transliteration into Perl install scripts would be appropriate.
I would agree, except the history of "develop it in an ultra-high-level language/environment and then port it later" has not been too encouraging: for whatever and various reasons, the ports rarely take place. But the idea of a MUD or MOO being a place to try out tools and then somehow get them "compiled" is a good one.
Exciting times.
You bet -- it sure is interesting to be alive in these "latter days". As his ex-Prince-ness has said: "We're gonna party like it's 1999".
More purple prose?
Of course, we'd better get strong crypto distributed before the Second Coming -- you think the current US government is involved in a power grab, you just wait!!! This new government will really know how to take care of non-conformists -- Waco is nothing compared to what they are planning (read: fiery brimstone)...
You'll find many on this list who agree with every point here.
I wonder if Jesus can create a number so large he can't factor it?
I haven't found one yet.
Pardon my excursion into various religious topics -- arguably this list is also about religion ("religion is what you do" -- "cypherpunks write code" -- belief that strong crypto should be widely distributed is certainly a religious tenet for some on this list). I hope I haven't offended anybody important...
I enjoyed your comments, for one. --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."
Pardon me for getting on a soapbox (again) T. C. May, for whom I have the utmost respect (and whose messages are always enlighting and enjoyable), says (in part): And "Byzantine Agreement" (is this the same thing as Byzantine Generals?) shows up, I recall, in some crypto papers. Yes, they are the same. You have N mutually suspicious individuals trying to reach concensus about something -- what protocol do you use? I believe the seminal paper (or at least some really good, polished, early work) was by Leslie Lamport at Xerox Parc (et al.), but I may be wrong.
Objects are Great; C++ (using objects, in I believe the way you mean) is clearly the language of choice for the virtually the entire
Yes, of course this is what I meant. That's why I mentioned the Smalltalk approach. (I won't get into issues of performance of C++ over Smalltalk and Lisp systems...my contention is that there's a vast amount of computer power out there and a (relative) shortage of good programmers and their time, and that this implies that only truly time-critical things or many-times-replicated programs warrant writing in lower--level languages. A religious point, no doubt.) Also a practical (== economic) point. When I worked at Mentor Graphics (MGC), I was amazed at the enormous percentage of effort devoted to optimization of our products (MGC builds the software to help design circuits that go in workstations that run MGC software that helps design circuits...). The _entire company_ (many hundreds of engineers) just about spent _years_ making a recent release small enough and fast enough to be commercially viable (luckily for me and them they succeeded -- of course, there were bug fixes and some enhancements added during the same time period). At MGC and now at EBT, efficiency (= responsiveness, = salability) of the delivered product is a virtually paramount goal, right up there with enough functionality. If functionality cannot be delivered with adequate efficiency, then nobody will buy it (except a few leading edge weirdos), and you go broke (MGC lost big bucks during this time period, and experienced at two or three waves of layoffs). If anybody can afford large, expensive workstations to improve the productivity of their superacheivers, it is computer manufacturers and their circuit designers (one of the highest paid engineering fields I know of). Their whole company depends (you may have guessed what I'm about to say) on the efficiency (production efficiency and efficiency in their target application) of the chips they are producing, for which MGC tools were (at least the primary) design vehicle. And yet it was cost effective to have me and many other engineers (also comparatively highly paid, but not compared to circuit designers I'm sure) spend several years trying to reduce the size of the object code (and working data structure size) for the tools. Earlier, when MGC was in the desktop publishing business for awhile (which is where I was most of the time), efficiency was a major, major concern. Keeping the size of data structures and code to a minimum was well worth the effort it took to design more complex systems. Every customer seemed to really care how fast our product ran, which essentially translated into how much physical memory it took to run the product. One of the major competitive advantages of our (now discontinued) product was that it handled extremely large documents relatively efficiently. But customers were always asking to make certain operations more efficient, and this was often on their top N list of enhancements. So, even using a "lower level language" like C++, even for a high end programming shop like MGC, even for not-many-times-replicated programs (I don't know how many seats MGC has installed, but it is somewhere in the tens of thousands), memory space was at a premium. I still _can not believe_ that after all the progress semiconductor manufacturers have made in the past 30 years that they cannot manufacture enough RAM cheaply enough to hold our software. This is truly INCREDIBLE! RAMs are still (at least as of a year or two ago) sufficiently expensive that a significant fraction (maybe 1/3) of programming effort must be wasted merely trying to keep memory utilization as small as possible. Ask how much time DBMS vendors spend on optimizations; it is huge! (Arguably, it is their entire business.) Compiler writers -- same thing (I did this in a previous job too). GUIs have to be speedy too, and people I know spend a lot of time adding performance hacks to speed them up. For real tools used in real applications, apparently customer expectations have increased _significantly faster_ than our ability to manufacture semicondutor components. People have always said that "sufficient" computing capacity (or network capacity, or what have you) will be Here Real Soon Now(tm), but it hasn't happened yet, and I'm not sure it ever will in the real critical applications where the rubber meets the road (and computer circuit design is one of them -- data retrieval, publishing, and networking are also). Of course, this is all relative, and Internet clearly has the bandwidth to support the CP list. My point is that in the real world, efficiency (however measured) is still a major concern for economic survival. I predict that efficiency of cryptography will be important, and it will be a long while before enough computer power is widely available to encrypt all data, sensitive or not (i.e. cryptography is cheap enough to not worry about whether to use it or not).
Food for thought. I'm wondering if a project to implement a kind of "Digital Money World," perhaps in SmalltalkAgents, wouldn't be an interesting project. (Many will probably tell me that a collection of Perl scripts would be more "portable" and more useful to the current Unixcentric community....something I'd like to see more discussion of.)
I suspect the framework of choice would be some sort of MOO or MUD. Of course, once it hit production status, then transliteration into Perl install scripts would be appropriate.
I would agree, except the history of "develop it in an ultra-high-level language/environment and then port it later" has not been too encouraging: for whatever and various reasons, the ports rarely take place. Right. Remember, Fred Brooks (in his classic on software engineering _The Mythical Man Month_) says to plan to throw one away. So you build the first one, and instead of porting it you redesign it from scratch. (Of course, then you might perhaps want to worry about his "second system syndrome".)
Of course, we'd better get strong crypto distributed before the Second Coming -- you think the current US government is involved in a power grab, you just wait!!! This new government will really know how to take care of non-conformists -- Waco is nothing compared to what they are planning (read: fiery brimstone)...
You'll find many on this list who agree with every point here. I hope my implied smiley was apparent here, and the McElwaine-like addendum (deleted by Tim) was hopefully enough to convey my true attitude...
I wonder if Jesus can create a number so large he can't factor it?
I haven't found one yet. What haven't you found -- a number you can't factor? Or a number that Jesus can't factor? (I bet at this moment there are a lot of them, for example "12".) Or a number that your deity (if any) can't factor? Or is this an implied-smiley-bearing reference to a potential delusion of grandeur on your part? Or are you and he really working on this problem collaboratively, in some metaphysical domain? If you are saying that you can't find a "Jesus" who can create a number so large he can't factor it, I would tend to strongly agree with you. On the other hand, virtually every person who ever lived can (with a little coaching, perhaps) create a number they can't factor, and there are plenty of living people named Jesus. Maybe it is just because you aren't looking in the right places... :-)
Pardon my excursion into various religious topics -- arguably this list is also about religion ("religion is what you do" -- "cypherpunks write code" -- belief that strong crypto should be widely distributed is certainly a religious tenet for some on this list). I hope I haven't offended anybody important...
I enjoyed your comments, for one. Thanks -- I always enjoy yours. --Tim May -- dat@ebt.com (David Taffs)
David Taffs writes: (quoting me)
Yes, of course this is what I meant. That's why I mentioned the Smalltalk approach. (I won't get into issues of performance of C++ over Smalltalk and Lisp systems...my contention is that there's a vast amount of computer power out there and a (relative) shortage of good programmers and their time, and that this implies that only truly time-critical things or many-times-replicated programs warrant writing in lower--level languages. A religious point, no doubt.)
Also a practical (== economic) point. When I worked at Mentor Graphics (MGC), I was amazed at the enormous percentage of effort devoted to optimization of our products (MGC builds the software to help design circuits that go in workstations that run MGC software that helps design circuits...). The _entire company_ (many hundreds of engineers)
(much of interesting story about Mentor Graphics elided to save space...)
If anybody can afford large, expensive workstations to improve the productivity of their superacheivers, it is computer manufacturers and their circuit designers (one of the highest paid engineering fields I know of). Their whole company depends (you may have guessed what I'm about to say) on the efficiency (production efficiency and efficiency in their target application) of the chips they are producing, for which MGC tools were (at least the primary) design vehicle.
Oh, but I think you're making my point! The "superachievers" (= expensive designers, engineers) were buying Mentor and Sun and Apollo and other workstations, and the CAD tools that ran on them *precisely* to allow these superachievers to operate at a higher "semantic level" than they would otherwise. That is, the various CAD packages, with features ranging from direct object manipulation (circuit elements, not just pixels) to silicon compilation (perhaps overhyped...), are essentially "HLLs" for VLSI and other design environments. Ditto in related fields. I'm sure David knows this very well, but it bears analysis in the context of tools for programmers. And the fact that Mentor was competing (not very successfully--and I was Intel in Aloha, Oregon from '80 to '82 and knew some of the folks who founded Mentor--same time as the even-shorter-lived Metheus) with Sun and with high-end PCs meant that speed was very important. I agree that a workstation that ran CAD software 3 times more slowly by using Lisp would not be desirable (I can remember a couple of silicon compiler outfits that attempted to sell Lisp-based silicon compilers). Howver, most programmers I see are not writing this kind of productized code. Perhaps this is just my bias, or the types of folks I see. Here on this list, Perl has been adequate. And it's just interpreted. Furthermore--and this is one of my main points--most of the really "neat and cool" ideas for crypto use, for crypto tools, etc., are not getting done not because the code cannot be made small enough and fast enough but because the "semantic gap" between our thinking about crypto concepts and the tools to sit down and write them is so great. (By tools I also mean "abilities" and conceptual classes (in C++ terms) or methods (in Smalltalk terms). I think we need a "Crypto Toolkit." Henry Strickland is talking about using TCL (a Berkeley-based C package, apparently used somewhat analously to Perl, but with some differences) to provide a set of crypto primitives. My mention of SmalltalkAgents was more in line with the notion of a "CAD" package for building complicated crypto protocols, with the distilled knoweldge of the "Crypto" Conference proceeedings implemented as classes and methods (even with objects named "Alice" and "Bob," if needed). This could of course be done in C++, with a class library of crypto functions. This is the "high-level language" sense I was describing, with objects that "behave as" digital cash, or communications channels, or even as agents like eavesdroppers, spoofers, forgers, etc. (I suspect you can see where I'm headed: an artificial ecology (cryptecology?) of cryptographically-aware agents, thus creating an environment for experimenting with and testing crypto protocols for release into the world. The object-oriented approach is to allow separation of functionality, so that the various distinct capabilities are truly modular and are not just different chunks of code in a large program, as PGP is currently an example of.) My conjecture: 70% of all programmers now coding in C and planning to learn C++ would be "better off" (more productive, more maintainable code, fewer reinventings of the low-level wheels, etc.) with higher-level languages. "Rapid prototyping" is another buzz phrase, but an accurate one. In cases where one's reach exceeds one's grasp, as appears to be the case with all of these crypto ideas, bridging the semantic gap and actually getting something out is, I think, much more important than having it run faster (but not be built at all....). --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)
-
dat＠ebt.com -
paul＠hawksbill.sprintmrn.com -
tcmay＠netcom.com