6 expanded posts ยท every known parent and child
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."
...
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."