[How...1997] Quoting Black Unicorn :

Legal liability is the big issue. By "continuing personal involvement" I will assume you mean acting as an officer of the company.

I was trying to distinguish involvement as an officer in a development company vs. a deployment company, but yes.

[money laundering liability for users and/or operators, seems clear]

While this might not directly impact the person running or developing the system it certain serves to discourage users of the system after a single allegation has been made. Customer flight would be awfully dramatic I suspect. This makes a system which is bound (by design and definition) to be political unpopular also highly subject to political interference.

It's the civil provisions that I find more alarming though. One dollar of laundered money in an account subjects the entire account to seizure. That's not a good thing and assuming any ecash system had correspondent bank relations (a safe assumption if you know anything about financial systems.

No. Ecash for widespread public use is just not a viable proposition at this point. Even less so after 911.

I am not as interested in the risks to a monolithic electronic cash system, holding accounts at Bank of New York and a few others, developed internally, where all user funds are pooled, but rather the most distributed system feasible. While the only way I can see to get a system deployed is for a single organization to develop software, and another or the same to operate or contract for the threshold number of services required to provide a decent end-user experience, the system could easily metastasize and decentralize when required. This has been the case with several fielded payment systems already. [based on the Ian Grigg 5-part model from FC99, Ian Goldberg/etc. change-maker model, and general best practice for ecash in 2001:] 1) a market which holds no physical assets, trading as a piece of software Since this component has no physical assets, it would seem only a technical challenge to keep it operating in the face of attack. 2) software developers developing code to a published specification, such that end-users can develop their own software, or select from competing vendors. This would allow some of the more "research" aspects to be undertaken by developers arms-length or more from those providing customization work to potentially at-risk clients. Open source and network software has many precedents here; gaming software in particular, given the US legal situation and tinges of money laundering risk. 3) issuers Aside from traditional forms of risk, issuers could differentiate themselves based on regulatory compliance or regulatory risk. Conceivably, entirely underground currencies (the "gold-denominated, opium-backed burmese opium futures" of yore) could operate, maintaining backing in effectively There is little or no reason for the issuers to have any contact with the developers, or with the market, or indeed even with end users -- only with (possibly anonymized and/or arms-length) the change-makers, or with server operators (again, possibly nothing but arms-length) 4) operators of servers A reasonable electronic cash system would be turnkey, at least at the scales likely initially. The only transactions a mint should do can be enumerated in a 1-page API. Integration with existing back-office banking systems, external payment systems, etc. is complex, but not necessary with the change-maker optimization. Assuming ultimate liability held by a single individual per currency, with only very large and infrequent transactions between backing store for currency, and bulk sales to change-makers, most of the access control or automated transactions can be deferred; a simple authentication and direct (logged) double-entry modification of values is enough. These parties would not need to hold any financial assets other than those required to maintain servers. One could further refine to "colocation provider" who sells a server, and a "systems operator" who, fully anonymously, installs and operates electronic cash software on those servers, connecting via anonymized ssh, paying for physical services in cash, etc. 5) [optional] holders of backing assets for issuers In the case of unlimited-liability by an issuer, the need for an external party to hold assets for the issuer is reduced. If the rate of transactions is reduced sufficiently, ease of holding large assets without risk (the trivial case is Cryptonomicon-style direct holding of large physical assets; for development purposes, I could easily hold up to USD 10m-50m in physical assets in a spare machine room without substantial upgrades to security...2-3 day latency, or issuance against personal liability, or issuance against large physical assets.) For reasons of auditiability, it is of course desirable to separate the trustee of such assets from the other parties, but this is just an optimization (which would decrease the discount at which an issue may trade; do it when the cost is exceeded by the benefit) 6) end-users This is perhaps the most complex issue, and probably worthy of a separate discussion. This is one area I think most ecash systems have failed at. You propose using banks themselves as customers; perhaps this is interesting, but I'm not convinced they would adopt a system in a realtime timeframe. I'd love to be proven wrong. I know of several legitimate applications which have market demands for certain restricted forms of electronic cash which would be early adopters, provided certain performance and reliability specs were met, with a certain degree of end-user usability. All of which could be achieved by the proposed system in a very early stage. 7) "change makers" Participants who hold one or more forms of electronic cash, operating as banks, corporations, or informal traders, and can exchange electronic cash for something of value, and optionally vice versa, with at least some subset of users. These could easily be arms length from everyone else, evanescent, and the collapse of one would have no serious consequences. I assume the electronic cash system, as the law is written today, WOULD be sufficient to serve as a "firewall" between change-makers handling the same currencies, and certainly against change-makers handling diverse currencies. This is the #1 question I have. If this is the case, then I think an electronic cash system is completely viable even post 2001-09-11. As long as shutting down one change maker's bank accounts would not affect other change makers, a system could withstand most of the "obvious" attacks. 8) supporting services Ratings services, tickers, derivative instruments, consulting for merchants, etc. are all services which could be done easily by arms length entities.

I assume that the suggestion is that a smaller operation, a grassroots one, would somehow fare better. I don't believe this is the case. More below.

I am suggesting a distributed system where each participant is expendable is far better from a deployment standpoint than a monolithic system. I am suggesting that for development purposes, a small, grassroots organization *is* vastly superior to a larger one.

Money Laundering is its own RICO. (See e.g. Elkan Abramowitz, Money Laundering: The New RICO?, N.Y.L.J., Sept. 1, 1992). Again and again, here and elsewhere I've cited cases and statutes that make it pretty clear that innocent third parties easily become the victims of money laundering prosecutions and lose their businesses, their checking accounts, college funds, their homes, etc. simply because their family run travel agency accepted a check from a drug baron they had never met to pay for his trip to South America. An ecash system, particularly a small one, simply has no chance once it is used for child porn once or twice. A large bank might get away with it the way large banks do.

I think a large bank's protections would rapidly boil away in the heat if they intentionally developed or deployed a system designed to go against the anti-privacy trend of the past 50 years. But of course they have no incentive to do so in the first place. I'm willing to accept that a change maker could be shut down easily if it were used for an unpopular purpose. The other participants would seem much more difficult to attack. And provided attacking one does not automatically take down other unrelated competitors at the same level, it shouldn't affect the whole system; the system will build in discounts based on risk.

Hawala systems are effectively 100% certain to be subject to laundering charges when discovered operating in the United States. They are not much more than primitive ecash systems. The timing for suggesting that such a system would have any legal lifetime is pretty bad given the current environment. The trend in such things in the United States is moving strongly AGAINST financial privacy, not towards it.

The only real risk is if the *demand* for financial privacy decreases, not if the cost to provide financial privacy increases. Perhaps if cost is driven past what customers are willing to pay for widespread applications, but I think there are enough high-value applications in the underground economy to support even a relatively expensive system. And if a given hawala trader is shut down, but cannot identify other hawala traders, except that they all use torn federal reserve notes as tokens, no action will be taken against the fed; others hawala traders will raise their rates to compensate, if risk is judged to be higher.

U.S. law is probably the most extreme, so that might be a safe assumption. (Perhaps Britain would be nearly as bad). What is missed here is that "the developer is not linked to the operation" is a very optimistic assumption. It's the developer that will have to consult on the implementation, on the security provisions, on deployment, designing against the threat model. Anyone who believes this process won't trigger the "knew or should have known" provisions is kidding themselves. Invoking the Terrorist example is probably extreme for discussion purposes but I doubt that anyone here, if they were to really think it out, would believe that the author would not be detained in a Federal Detention "Submarine" for weeks at a time in this case- direct involvement or not. The threshold for detention these days seems to be "knew someone who once met a terrorist."

This is the only area where I disagree substantially; I think a system could easily be developed such that initial developers were not necessary to continuing maintenance, implementation, security, etc. With a reasonable degree of initial effort, and a background in easily-modified open source development, at least. This does make it much more difficult for ecash developers to extract revenue from sale of software, which is why it hasn't been done in the past, but perhaps this is one of the many cases where it's far easier to accomplish something if you don't care about who gets the credit or benefit for it. Certainly arrest or questioning could be used as a harassment tactic, but I don't see much potential for successful prosecution here. Both are bad, but conviction is worse.

I suppose if someone wanted you badly enough they would make arguments which included conspiracy, money laundering, conspiracy to commit terrorism, conspiracy to commit murder, conspiracy to... [fill in the blank]. The BEST case scenario in the case that they wanted you badly enough (and doubtless this would happen in the example you cite) is that you turn states evidence, show them the best way to break or introduce a break/trojan into the system and fall into the pit of witness relocation, looking over your shoulder for the rest of your life wondering when the missing remnants of terrorist group X will come calling. There is that other cute clause too. "Material witness." Oops.

Certainly a developer in this case has every incentive to publish *every* known vulnerability immediately, simply to avoid this kind of pressure. Perhaps this would be an interesting general security principle for full disclosure -- full disclosure to prevent being blackmailed. Assuming arrest or questioning regardless, I don't see how the probability of conviction on felony charges for simply writing software to do bits is high enough to change anyone's actions. Seizure of assets, arrest, etc. would definitely be enough to deter many people.

...

I would be annoyed by spending a year in a federal jail, but it wouldn't seriously impact my life.

I submit that this belief indicates you've never seen the inside of a federal prison. Remember also that terrorists don't go to Danbury. They go to the Supermax in Colorado. Also, most states have money laundering statutes too. You'll be lucky not to do time in both a state and a federal prison during the course of your ordeal if things get nasty enough.

I think this is a risk/reward/accessibility thing. If each component of a system is broken down into individual components with some legal protection between layers, it's much easier. Anyone who could implement all of the pieces and operate them all is a very small set. These people would most likely face substantial risks (if they break any law in the process, they could be convicted; and simply an attempt at prosecution or even a civil lawsuit could be crippling), and there would be little incentive for them to do so. However, if each component is analyzed separately, it opens up a much larger set of potential participants, and the risk/reward profile of each is better. Software development is about as risk free as anything in the system; the reward is perhaps lower, but the level of skill is relatively high compared to some of the operational actors, so that increases the likely reward. The highest risk components are also the least skill-intensive, and could have effectively unbounded rewards (set by the market and competition). This is as it should be. In drugs, high profits belong to those who control monopoly assets, have large amounts of capital, etc. ("high 'skill'"), and they are relatively low risk. Highest risks probably belong to individual street workers or couriers, which are very low skill, but moderately high reward, depending on risk.

...

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.

Doesn't have to stick. Why would you think it has to stick? People are incarcerated on little or no evidence all the time, particular if they are involved in politically unpopular activities- otherwise totally legitimate. (No more guns for you either as a convicted felon).

Conviction, yes. But you've not shown how software developers, or indeed most of the participants, would be subject to anything but civil or criminal-harassment, and it appears the balance of evidence is that those who just develop software are unlikely to be convicted. I personally would be far more unhappy with being arrested and convicted immediately for 1 year, than arrested, held without trial or conviction for 2 years, and then released. This is why developing software or hardware is more attractive to me than couriering drugs or money.

Asset forfeiture can include garnishment. That can last quite a while. I doubt you want to be big enough a deal to be known by name to Ashcroft. I'm sure it might be interesting to be a famous hacker a la Mitnick and bask in the glow of contraries rebellious reputation you'd gain among all 17 year old suburban males running a Morpheus supernode with all the albums of Metallica ever pressed. I doubt its worth it.

Hah :) "Hacker" is rather limiting. Electronic cash, if it enhances the underground economy, is far more meaningful politically than any non-economic online activity like trading files. Of course, success in this is directly related to unpopularity with the government.

...

(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.

Legal problems or not, and different members of this list will have different views about how realistic it is or isn't to be harassed over writing some code. In the end it makes little difference. The problem with ecash is that it doesn't do enough things significantly better than current solutions for a retail system. It does some things much worse. I've always believed that the best deployment would be in a interbank role, where clearing and settlement actually have important time components- counter-party credit, Herstatt risk, etc. and the sums are large enough to make small to moderate improvements in performance important.

I believe there are some applications for electronic cash which, if it met certain minimal standards, would be sufficient to make it self-supporting. These applications are relatively free adopters of new technologies, especially compared to financial institutions. Gaming and pornography would be highly suitable, given recent actions by credit card issuers, complete security failures by ccbill and others, inherently high fraud rates, etc. I don't think anyone has seriously proposed ecash as a retail widespread purchasing system to compete with credit cards since the mid 1980s. Applications in equity markets are also interesting. Micropayments seem to be a waste of time, although there are some applications for which they might be suitable (specifically, the "electronic postage paid to recipient of email to read it, as a bond against spam" is one of the most interesting ideas I've seen, and given the right software and UI, could actually be interesting and worthwhile...I would put 2-3 months into it if there were a pre-existing electronic cash system to integrate) There are numerous underground economy applications which are interesting from both a market sense and a political one.

...

Mainly what is important is to do as little work as possible...

Coding is hard, let's go shopping?

Indeed, code or protocol re-use, elimination of complexity, etc. are good for all software projects, especially "cypherpunk" ones.

All this illustrates an important principal. Secrecy and limited liability, by necessity, have a zero sum relationship. As you increase secrecy you must decrease limited liability in step. "Secret, Limited Liability, Successful, pick two." The combination of limited (non-existent) liability and secrecy is simply an impossibility for a financial organization. "A Small unknown and poorly financed firm" might as well be limited liability for our purposes- no one is going to see a dime back from it if it fails. Also, note that unlimited liability has a much stronger assurance quality. (See e.g., Enron, FDIC insurance for the failure of "disclosure" to properly compensate for limited liability or moral hazard).

This is a very very good point. I am proposing separating pieces of a fielded system such that each can have its own secrecy/limited liability profile (assuming they all want to be successful). Issuers, perhaps, can be of both kinds. Software developers are, for the most part, non-secret, but limited liability. Change-makers can, through technical restraint, be completely "open" in certain ways -- to make it clear that they must make good on transactions -- and completely secret in others. Markets, operators, etc. are fairly impotent to do anything outside very limited technical tasks, which should be widely publicized. I would argue that technical "code-based prohibition preemptively, vs. prosecution after the fact", or "code not laws" is about the same as "limited liability vs. secrecy" -- after all, isn't removal of ability to do something a traditional way to reduce liability, as an insurer?

Additionally, based on my experience doing business with cypherpunks there is no hope for "business credentials without identity" amongst those who should be the most receptive to it. (The due diligence demands of cypherpunks I've encountered in the business world far exceed those I endured at the hands of European banking authorities). Then again, perhaps the paranoia of cypherpunks types is better developed than that of European banking authorities. (That could be taken many ways, depending on your view of European banking types). I suspect that you might find that a small ecash project, which by its nature would appeal to cypherpunks as clear (and perhaps the only) first adopters will find that most cypherpunks "would not invest $1 of my own money in such a thing." That should be all that needs to be said about the viability of a "small ecash project."

Perhaps one might make a distinction between the development of an ecash system and its deployment, but I doubt it will make much difference. The basic tools of ecash have been floating about for some time.

The reason I'd be unwilling to invest any money (but not necessarily time or other resources) into an ecash software development effort is the "moral hazard" of externally-funded startups, as . Perhaps it's that I've seen some of the worst of the dotcom boom from California and am still reacting to it. I think the only productive ways to introduce external capital to electronic cash would be: * Providing non-divertable resources (computer time, office space, etc.) to development efforts, perhaps based on progress. While I think 20 people making $200k/year in a luxury office in San Francisco could easily waste $15m furnishing an office (12 Entrepreneuring...), there are only so many cheap laptops, dormitory-grade accomodations, and rackmounted servers you can use to enhance your quality of life; 1 Bentley is worth more than 80 Cutlasses. If the funds go to actual tools for the development of software, and are meager enough to not be a desirable end in themselves, a lot of the apathy hazard disappears. Of course, the resources needed to develop this are exceedingly modest. It's easier for me to divert some of the capital and facilities I have now to work on projects such as this than to do anything else; office space, hardware, accomodations, servers, etc. in the north sea cost me effectively nothing for even a moderately-sized development effort. (until maybe September 2001, though, my time has been very limited) * Providing financial rewards based on public accomplishment of milestones. If there were funds which would be paid based on "electronic cash included by default with shipping versions of MS IE", only successful efforts would raise money. I can put some money toward this if anyone else wants to develop a system (although specifying the winning conditions is complex). Of course this does possibly put the funds of those providing the prize at risk. One reason why I'd be reluctant to do this (plus that if I did it, it would be on the scale of thousands or tens of thousands, which is perhaps not sufficient motivation for anyone), is that "task market" systems have all failed in the past. This is different in that it is more a "bounty" a la lindbergh or x-prize, vs. a generalized system. However, coming up with a good external specification and judging for this is more complex than the conditions for either of these aeronautical feats. * Ensure that once a system is developed, it can actually be deployed; I'm sure amateur development efforts in ecash would have gone ahead long ago if developers had not been concerned with deployment, legal issues, etc. If it were *just* a software development effort with a defined deliverable, it's interesting to people with a different risk/reward/skill profile than "develop this and maybe it will get deployed, maybe it will be shut down by patents, maybe it will be shut down by the authorities, maybe it will be used by enough users, maybe you will get some reward." The tools that exist today are beyond the ability of those with the risk/reward/skill profile to be willing to use them to be able to use them. Thus, there is no ecash deployed. If ecash could be reduced to a "push this button" level of skill, I believe at least one of each necessary actor would find it within his risk/reward profile to operate. I certainly find it within my risk/reward profile do any but not necessarily all of hosting ecash servers for others, run a trial currency as an issuer, participating as a user, operating a limited market, and perhaps even acting as a change maker on an informal basis. (but doing all of these is obviously poor).

I submit that we should endeavor to find a motivator a bit more solid than that it would entertain the developers. It sounds suspiciously as if you might need an entertainment center in your dot-com campus. Entertainment for the developers is, of course, what the firm is in business for. (From what I know of you that's a bit shocking to hear. If that's all the case then just write the damn thing and distribute it via usenet, Mr. Lackey).

Well, in the split system, I think "writing code for entertainment value only" could easily be sufficiently high motivation for one of the many people who can develop such software to do so. Certainly, it has been in the past, for Pr0duct Cypher and others. I believe if the problem were reduced to *strictly* a "write code" one, ecash could be developed as easily as any other fairly complex network/cryptographic system which touches on finance -- more difficult, surely, than ssleay or , but less difficult than an ERP system, and probably less complex than NCSA Mosaic (given the right background). Very few people participate in high-risk activities, even low skill/capital ones, without being paid -- almost every drug dealer I know is in it for financial reward (with some lsd/e/hallucinogen dealers perhaps being more interested in political or social change). In the system I propose, the high risk components are competitive and compensated, other components are low risk with acceptable reward and relatively low skill, but there unfortunately remain some low-risk, high-skill, uncertain reward components, most specifically initial development and stage-0 deployment of test systems. The only motivation I can see which will actually be sufficient for ecash software to be developed is if the developers find the exercise itself intellectually rewarding, and the potential consequences worthwhile. Ecash development is not a *rational* economic choice, at least in terns of short term rewards. Throwing money or toys at the problem is not going to change this, as I may be overly cynical, but I think the probability of a product goes down proportionate to the amount of money invested over the bare minimum necessary; and for ecash that is $0. (perhaps the corollary is that those who could most easily develop ecash at this point have "lack of ecash" costs as a substantial existing item, and thus *could* spend up to that amount to develop it without causing negative feedback; but this is a pretty tortured argument, there are agency problems, etc. Although, I suppose the cost to me personally of not having ecash is in excess of USD 500k, in that havenco can really only go public on an ecash-based market, and I can only easily realize value from my equity through such an offering, discounted of course for ecash deployment costs, risk, forgone value from private sale, etc.) If the probability of any individual developer finding this to be sufficient reward is too low for one's taste, one should attempt to increase the set of efforts which could possibly develop the software. Perhaps the dotcom collapse, by putting a lot of people back onto the job market with uncertain prospects, will increase this set; perhaps better programming environments which lower the skill required to do cryptographic and network programming will do it; perhaps the expiration of patents and dying down of patriotic hysteria will reassure developers; perhaps legal analysis of the risks to pure developers will lower it; perhaps high visibility persecution of p2p systems, dmca-violating tools, etc. will motivate a new generation of programmers; perhaps computer science education will improve. (I personally find working on such software very interesting and rewarding, even if it is destined to do nothing more than be a published, working, but unused curiosity, but despite this, external circumstances have caused me to focus on "my real job" for much of the past year. I'm quite happy to spend some of my spare time working on such a system, and hope this spare time increases in the future, but I think there are some other, smaller, more easily accomplished and deployed systems which I will release first -- mail and associated utilities, perhaps a simple proxy, productization of some internal management and automation tools, and thus the process will be a bit slower than it could be. If someone else were to develop a suitable system first, it would save me quite a bit of effort, obviously, and I could contribute what I have so far, but I'm not exactly holding my breath for this.) -- 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

-----Original Message----- From: owner-cypherpunks@lne.com [mailto:owner-cypherpunks@lne.com]On Behalf Of jamesd@echeque.com Sent: Monday, December 24, 2001 10:04 PM To: Ryan Lackey; cypherpunks@minder.net; Black Unicorn Subject: Re: Liability, economic realities and self delusion in ecash developers. Or: Why not "just write ecash" (again).

-- On 23 Dec 2001, at 21:39, Black Unicorn wrote:

...

While this might not directly impact the person running or developing the system it certain serves to discourage users of the system after a single allegation has been made. Customer flight would be awfully dramatic I suspect.

You are as usual full of shit.

If this was so, ever banking haven, e-gold, and the rest, would be out of business.

You have remarkable confidence not only in the effectiveness of laws to deter those things they directly prohibit, but even those things that are sort of vaguely like those things they directly prohibit "Mr Happy Fun court will not be amused"

Every business continually commits numerous major illegal acts, and every day must do innumerable acts that would doubtless fail to amuse Mr Happy fun court. So much is illegal that legislation has little effect even on those things the legislation directly prohibits.

So what's your point?