[Webfunds-users] Napster for Money?

Sun, 15 Apr 2001 11:08:13 -0400

Linas Vepstas wrote:
> 
> Hi,
> 
> I'm the lead developer for GnuCash (www.gnucash.org) and I've been
> eyeing webfunds (and other electronic money systems) for inclusion
> into GnuCash (an open source (GPL'ed) accounting/finance
> application). 

That would be interesting.  Is it written in Java?  There is
another accounting package for which the same thing was suggested,
Moneydance;   I guess we are talking about adding a plugin to do
what you would call "remote payments" (possibly also erroneously
labelled as Internet banking in our case).

Of the other ones you are looking at, would I be right to guess
at e-gold and PayPal?

> Any actual work is not likely (our list of desired
> enhancements is longer than my arm), but its fun to daydream every
> now and then.   My curent scary daydream 'napster for money'.

Do you mean, Napster with money built in?  Or, Money built on a
Napster model?

> So, with that in mind, some newbie questions:
> I read almost every page on the website, and I swear, I still don't
> understand how it works.  In fact, I'm so confused, I don't know
> where to begin.

In practice, we simply don't know how to write the doco to get
people up to scratch, basically you have to try it and discover
your own path.

> Some 5-6 years ago, I read some whitepapers about using crypto for
> e-cash. I remember only the vaguest generalities, still, nothing in
> the ricardian contracts seems to match.  I would really, really,
> really appreciate an Alice-Bob explanation of how it works.

That work was based on David Chaum's blinded token money.  WebFunds
doesn't use those ideas, but achieves something similar with 

> (BTW, the url for Edinburgh Financial Cryptography Engineering
> efce.org, seems to point at european federation of chemical
> engineers, and so the slides aren't viewable).

&@^*&^@What?  I'm checking that, you are right, it's moved.  It was
paid up until recently, something's skewed there.

> My confusion has to do with what roles the mint, the banks and the

OK, a word of caution.  There are no "banks" in this system.
Banks are financial institutions that borrow money from the
public in the form of "deposits" and lend it to the public.

In contrast, Ricardo/SOX implements payment systems.  You
can purchase money for money, but you cannot make a deposit.

Deposits are legal loans wherein the bank has first claim on
your money.  In general, the Ricardian Contracts are specifically
written to exclude the notion of a deposit, as that introduces
risk into the system.

In our world, we talk about Issuers of a valuable instrument
such as a currency or a share.  These Issuers would hopefully
write a contract that gives the holder of the instruments 1st
claim on reserves.  Of course, we don't write the contracts,
and it is up to each holder to assure themselves of those
details.

> individuals play with respect to each other.  Is the reicardian
> contract between the individual and the mint? Between a pair of
> individuals?

A Ricardian Contract, when served on an Issuance Server, is
between the Legal Issuer and the individual, or holder of
the instrument.  If you hold some instruments, then you are
protected and served by that contract.

The mint is a special, background role that causes value to
be created within the system, generally infrequently and in
big lumps.  As the system is designed not to allow the random
creation of value, we need a special bootstrapping method in
order to create legitimate value.  That is done by the mint.
(The mint contractor is bound by contract, in general, but 
that is not the same as the Ricardian Contract.)

> If A received value from B, how can A send value to C?

If you (Alice) are using WebFunds, and you have received
value from Bob, you can simply make a payment out to Carol.
That's a feature of the user software, like WebFunds.

> Must it involve a 'market maker/trader', or can A & C exchange value
> privately?

Any two parties can exchange or deliver value privately.
Anyone who holds Ricardian Instruments has ownership to them,
and ownership can be disposed of without additional intermediation,
in general.  There are some exceptions to this, but they are out
of scope here.

> If thier interactions are 'public' (i.e. must be mediated
> by a 'bank/mint' running a 'server' somehwere), then can they still
> be anonymous?   What prevents A from spending the same 'value' twice?

All online software electronic value systems are mediated by a
central server which maintains accounts in some form or other.
That's how Alice is prevented from spending twice.

(In offline hardware systems, where the token is inspected on its merits,
and not cleared through a central server until later, the trick is
different, and somewhat complex.  We don't need to worry about that
with online software systems.)

Being anonymous:  to be pedantic, no.  But they can be private.
In the SOX system, they are nymous, which means they are identified
by a nym, or psuedonym.  This is a constructed name or handle that
is unlinked to any other information.  For the more cryptographically
inclined, the nym is the public key.

In other systems, like blinded systems, the transactions are
untraceable.  In practice, that means that Alice and Bob are fully
identified to the Issuer (or, they call it a Mint), but that they
cannot be spotted spending value to each other.

We do things in reverse:   Alice and Bob are nyms, so we can't see
who they are.  But, we can see when Alice and Bob spend between
each other.  This is psuedonymity, whereas the blinded system
achieves untraceability.  (And, no system achieves anonymity in
any useful sense, again, to be pedantic.)

In summary, all these systems achieve a measure of privacy.  How
much and which is better is an endless debate only for the patient.

> I suspect the answer to that last question is probably easy, once I
> 'get' the paradigm. But I sure don't get it yet ...

I wish it were easy....  In technical terms, you create a key,
and register that key with the issuer.  You now have a nymous
account.  You can make and take payments in any instrument that
the server handles.

The accounts are what we describe as lightweight -- they are
created on the fly and disposed of as desired.

> (There's a host of related questions that I'll ask as soon as you
> answer the above; many of which might have trivial answers, but
> still...: for example, what happens if someone breaks into my
> computer and 'steals' my wallet (i.e. makes a copy of it)?

In technical terms, you're toast.  Copying the keys gives you
access to the asset.  In business terms, it depends on the legal
issuer concerned, that legal issuer may be able to recover some
money, or all of it, depending.  However, it is a complex expensive
process, and you have to provide all the information that is needed
so that the tracking can start from somewhere.  And, in practice,
if the thief is any good, he's flown before you know it.  Also, if
it is anything less than a significant amount, the recovery won't
be worth it.

It helps to think of the keys as the asset.  Lose the keys and
lose the asset.  It will be important in the future to think of
securing those assets.  What that means, skipping over a huge
amount of analysis and experience, is putting the assets onto
a palmtop-like device that can be secured against viruses and
the like.

It also helps to realise that this is not banking, and not credit
cards.  The user is not "protected" by any magical means.  There is
a reason for this -- the system is built to perform for particular
applications that need this;  it is not designed to replace credit
cards.

> What
> if I was to aid  and abet such an action?

That's a legal issue between you and the Legal Issuer.  The tech
can't really answer that one :)

> What about the
> 'man-in-the-middle' attacks?  Can someone pose as a bank,
> and if so, does it matter?

Can someone pose as the Issuance Server?  Hopefully not, as the
protocol is designed to prevent that.  The Issuance Server has
a whole bunch of keys that are used to authenticate it, and if
any of them change, the protocol will dump the connnection as
being bad.

> What if a cracker got into the e-bank
> server?

"In theory" anything can be hacked.  In practice, difficult.

We use FreeBSD which is one of the more secure operating systems.
At the moment, we just use single machines, with nothing else on
them (so, no other ports open, firewalled, etc).  Later on, when
the values exceed some threshhold, we have plans for layered defenses.

> What sort of damage could be done?

All sorts of mess could be created of course.  But, fundamentally,
it would require a hugely coordinated attack, because when it is
detected, we would simply shut down the servers, repair the damage,
and backtrack the transactions to isolate where they had gone.  This
is the advantage that the nymous approach has over the blinded
approach -- in the event of the meltdown attack (as Mondex phrased
it) the nymous accounting can be rectified.  Blinded accounts cannot
be repaired.

So, what results is that the perpetrator would have to get in,
get the "cash" out, and then would have wash it thoroughly before
discovery.  For various business reasons, like how the market makers
work, and the slowness of the outside financial system compared
with the speed of online auditing, that can't be done with significant
amounts without raising lots of red flags.

> What happens if
> the e-bank or issueing authority is disreputable, dishonest, etc.
> Can they damage the entire 'float' or is the damage limited? )

That's why all the different roles exists - to separate out the
creation of float, the running of the servers, etc.  If the
Legal Issuer is disreputable, his best option is to take the
reserves and run.  So, what we do there is encourage the reserves
to be on public display (see the webfunds contracts page for some
examples).  And, we also encourage co-signatories.

> I hope you can answer these questions ... (and BTW, I think it would
> be good if you did so on your website; a clear description would
> engender a better understanding, and thus, hopefully, encourage
> a broader acceptance of what your doing.)

Most of the governance in detail is an issue for the legal issuers, and
such is more documented on the www.systemics.com/docs/ricardo/issuer/
page, as it is arcane and dense, and Issuance is Systemics' business.
The WebFunds project itself is concerned with delivering the fruits of
the Legal Issuers' labour to the user, in the form of an application, etc.

-- 
iang