Liability, economic realities and self delusion in ecash developers. Or: Why not "just write ecash" (again).

[Ryan Lackey]

[How...1997]

Quoting Black Unicorn <unicorn at schloss.li>:
> 
> 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 at 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