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

Black Unicorn unicorn at schloss.li
Sun Dec 23 19:39:13 PST 2001



> -----Original Message-----
> From: owner-cypherpunks at lne.com [mailto:owner-cypherpunks at lne.com]On
> Behalf Of Ryan Lackey
> Sent: Sunday, December 23, 2001 8:01 AM
> To: cypherpunks at lne.com
> Subject: ecash developer software liability, round 809834

[There isn't much new to talk about 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?

I think I can speak to this with some degree of experience.

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

The most serious level of legal liability that concerned me was the
potential for criminal and civil sanctions for money laundering.  I am
constantly amazed by the level of self-denial cypherpunks have when it comes
for legal liability in this regard.  (Usually this is justified with some
cutesy-clever technical argument- as if no one had been watching the
Napster, eGold or RIAA developments at all over the last few years).

Money laundering is a slam dunk for prosecutors and very tempting to use
because of its connotations to a jury/defense counsel.  It is simple to
allege.  It also has MAJOR impact on potential sentencing.  Consider:

"Analyzing actual cases, the working group found that money laundering
charges most often involved a relatively routine financial transaction
(e.g., depositing, wiring, transferring, withdrawing money) that was
essentially "incidental" to an underlying crime (e.g., a fraud, gambling
offense, or drug sale) that the defendant charged with money laundering had
also committed. The working group concluded that while the underlying crime
usually appeared to be the real gravamen of the overall offense conduct, a
money laundering count could generate a guideline offense level that was
quite different from that of the underlying offense, and, as a consequence,
greatly influence the sentence."

"With respect to what the working group categorized as "white collar"
offenses (i.e., fraud, embezzlement, import/export violations, and copyright
infringement), the working group found that the addition of a money
laundering count raised the defendant's offense level 96% of the time, and
frequently to a significant degree. For example, in one reasonably typical
case examined by the working group, the defendant had committed a fraud and
deposited the proceeds of the fraud in the bank. Consistent with court
decisions construing the money laundering statute, the government charged
the deposit of the fraud's proceeds in the bank as money laundering, in this
case for "promoting" the fraud by allowing the defendant access to the funds
for personal use. Pursuant to the fraud guideline (2F1.1), the offense level
for the underlying fraud was 19 (guideline range of 30-37 months for
defendants with no criminal history). Pursuant to the money laundering
guideline (2S1.1), the offense level for the money laundering offense - -
here, promoting the fraud by depositing the fraud's proceeds in the bank for
personal use was 28 (guideline range of 78-97 months for defendants with no
criminal history). Thus, the addition of the money laundering count in this
case substantially increased the defendant's sentence."  (United States
Sentencing Commission Report).

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.

> (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 believe it is.  Given the current state of the law money laundering might
as well be the anonymization of transactions for unpopular purposes (the
entire purpose of ecash).  It is a political definition, not a technical
one- much as "terrorism" has become.

> 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)

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.

> 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?

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.

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.

> 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)

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

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

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.

> The DMCA/Dmitri case is certainly one of the most recent, but the end
> result was effectively nothing.

I'm not sure Dmitri would agree.  Regardless, the issue was much different.
Dmitri wasn't a U.S. Citizen.  I daresay the situation would have been
entirely different (worse) if he were.  This was effectively a civil, not a
criminal action, despite DoJ noise to the contrary.  You're not dealing with
the prosecutors in the organized crime/money laundering group who are a lot
more cut-throat (and a lot more experienced at cutting throats).  Copyright
and DMCA are a fairly new area and attract young and inexperienced
prosecutors.  The result is a certain uncertainty and experimentalism with
techniques and legal theory.  None of these failings will afflict a
prosecutor in the money laundering/organized crime sections of DoJ.  These
people play for keeps.

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

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

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

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.

> Being murdered by the state would also
> be unpleasant, but is at least fairly rare and unlikely.

Agreed.

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

You haven't been watching the last 3 months have you?

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

See, all the arguments you make by comparison apply equally to Napster.
(Particularly insofar as they ignored the potential liabilities and civil
actions when they designed the system).  Let's face it, if there's no market
for ecash what's the point in developing it.  Cypherpunks are remarkable
socialist when it comes to ignoring market forces in order to favor the
develop a "cool" and esthetically pleasing system that no one will use.
This is unfortunate.

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

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

Coding is hard, let's go shopping?

> 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,

In other words the market for it?

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

"Start-up" is the part that trips it up, not "large and collaborative
project."  At least, insofar as "start-up" means "spend untold millions
hiring 150 recent college grads for $120,000 a year, trying to beat
Microsoft for 'most opulent campus' hiring a 'start-up advisory' firm to
clean the mess up after your third failed follow-on financing and otherwise
acting like idiots."  Competent firms, and competent managers don't do such
things.  (Granted they are few and far between since 1997).  Don't paint
dot-coms with a brush so wide it slathers legitimate ventures as well.

As for small ecash projects you might want to consider something.
Historically there is a certain group of firms that are among the, if not
_the_, most stable and reliable financial institutions.  Those are closely
held private banks.  In Switzerland, Austria, and once in Italy, these are
subject to unlimited liability.  (Usually they are unlimited general
partnerships).  That means that the owners are fully liable for all the
liabilities of the bank to the extent of their entire set of business AND
personal assets.  Usually they are run by well known families with
substantial fortunes.  I am not aware of any of these institutions failing
(or indeed failing to make a profit) since they have existed (provided there
was an heir apparent to the institution in existence- eliminating the "last
round" problem).  At the same time these firms provide little, or indeed NO
disclosure over their activities or holdings either to depositors, or to
authorities.  One firm I know of pays the same amount in taxes every year,
even if they owe less, to prevent any reverse engineering of profits.  This
same firm returns 17%-20% regularly on their "Silver Fund" for which no
prospectus or description is available- even to investors.

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

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

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

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





More information about the cypherpunks-legacy mailing list