(round 809834 because I'm sure this has been discussed 809833 times at least on this and other lists, but google hasn't found anything interesting for me) (I was going to try to make a long posting on what I felt were the good and bad of the state of play of ecash software development at the end of 2001, but then I spent a few minutes poking through cypherpunks archives and realized that's not much new to say which wouldn't need to be explained in context not a lot of people have. I'd rather spend the time this freezing winter day developing some useful software instead. (configuring some semi-useful software, rather, right now) So instead just a few questions.) What exactly *is* the legal or security liability if a person of independent/offshore means develops and delivers an electronic cash system in an open-source fashion, optionally with no continuing personal involvement in development, or optionally with continuing personal software development involvement but no operational involvement? How much of a difference do the various levels of removal make? (in place of "ecash" feel free to substitute "anonymization", "datahaven", "p2p", "assassination politics bot", etc....the argument is probably generalizable to any unpopular code which involves money and privacy.) I'm unconvinced it's possible to develop any large piece of software in a truly anonymous manner; anyone who *could* develop ecash has enough information available about them online to understand what they did, especially for something as intellectually complex as a workable, vs. minimum-effort, ecash system. There is a small enough number of people who could develop such a thing that a bit of research would show which ones spent every day for the past 3 months shirking other professional responsibilities and contacting credit card processors, writing code, etc. (plus, of course, ego reasons make it unlikely the developers of such a thing could remain anonymous)
From nothing I've seen is the risk anywhere near as substantial as some would suppose. Worst case with ecash is that it is ONLY used for criminal operations; perhaps the ecash operator could be attacked under RICO? I think perhaps the developer could be named if there were more than arms-length interaction between developer and operator, but this becomes more difficult if post-development the developer disclaims ownership. Lets say it is used by real terrorists to finance the purchase of weapons for a weapon of mass destruction, in a single transaction, with no other uses. As long as the developer is not linked to the operation of the system, and the operator of the system is not linked to the end parties, I can see legal or extralegal harassment. (I am perhaps naively assuming US law is the only law which matters; this may not be the case)
But what is the absolute worst thing that will happen? Extralegal quasi-governmental execution? Indefinite imprisonment without trial? Successful prosecution under some law? Asset seizure? Being declared a bad person by Ashcroft in a press conference? Not getting invited to FBI agent parties? Scorn and slight regard? You can't "unwrite" code, and if something is done and shut down, but doesn't fail for fundamental reasons, it's just a matter of time before someone else picks up the still-shiny unbroken tools and starts again, perhaps a bit more carefully. If people stopped slanging rock every time someone on the corner got knocked, the ghetto would have a lot fewer BMWs. The DMCA/Dmitri case is certainly one of the most recent, but the end result was effectively nothing. I would be annoyed by spending a year in a federal jail, but it wouldn't seriously impact my life. Being convicted of a felony would be slightly more unpleasant, but not substantially so -- not that I'm convinced there's much which would stick. I don't really need to worry about asset forfeiture, being declared "evil" by Ashcroft would be worth it, and I doubt I'd get invited to FBI parties anyway. Being murdered by the state would also be unpleasant, but is at least fairly rare and unlikely. A media/government character assassination attempt would be unpleasant as well, but would be difficult to make stick given the disrespect large segments of society have for the government and media already. If the risks of developing ecash really are overblown, perhaps that will make it more likely people would actively develop software. That is, aside from the standard "ecash is a complex system technically", "we need money to buy aeron chairs and feed ourselves", "you need to be able to both develop and operate a system to bootstrap, and these are different skills", "it's easier to spend time debating why such a system can't be done or hasn't been done than to actually develop it", "how will anyone make money from it?", "writing code is hard, let's go shopping", "crypto-export regulations", "many have tried, all have failed", "the actual lack of any clear market demand for such a system, and active opposition on many grounds by those necessary to deploy widely", "if I wait long enough someone else will do it for me, and I am lazy", "moral doubts about the goodness of a world with such a system", "the patent thing", "x, y, and z will sue civilly", "writing papers and going to conferences/grad school/etc. is more fun than writing code", and "the fact that a lot of crypto-software developers are even flakier than normal software developers." (I don't think just releasing code is productive, but I think there is a code+limited deployment which would be productive, and is not substantially more effort. I think there are certain technical decisions which must be made by an ecash system with some knowledge of how things are done in practice, but there have been ~10 attempts at developing such things in the past, with lots of info available by talking to the developers or being involved. Mainly what is important is to do as little work as possible, the ultimate goal of any software engineer, and to make sure that as little work as possible is required to use the system. There are certain very minor design, API, and UI decisions which would logically have a very large impact on user perception (end user and developer), adoption rate, and terminal success. I also believe in "start small and imperfect, iteratively improve in a mostly hill-climbing fashion" and some other very simple rules of [open source/internet] software development which have not been followed by previous projects (some of which I've learned myself at some cost). I share the belief that a capitalized, startup-style, large and collaborative project is entirely the wrong way to go about things, and would not invest $1 of my own money in such a thing, but I disagree that it requires any substantial technical *programming* skill beyond any other moderately-complex network + crypto programming library; mainly one needs to know how to avoid doing work. Since to be useful the system must be integrated into applications, a lot of thought needs to go into how to design it to encapsulate nastiness, and integrate with a wide variety of applications. The number one thing required to successfully develop and deploy an electronic cash system today, though, is being simultaneously smart enough to be able to do it, but stupid enough to do it anyway, even given the past failures, lack of rational economic motive, and potential risks. People often do irrational things; sometimes this is constructive, other times it is not, but it's usually interesting, at least to me.) -- Ryan Lackey [RL7618 RL5931-RIPE] ryan@havenco.com CTO and Co-founder, HavenCo Ltd. +44 7970 633 277 the free world just milliseconds away http://www.havenco.com/ OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F