Brands excluded from digicash beta

-----BEGIN PGP SIGNED MESSAGE-----

Last month I complained that my multiple attempts to request an account
to try out the digicash beta-test ecash system had been ignored.  I got
half a dozen replies from people who had had exactly the same
experience.  Shortly afterwards, though, I got email from digicash
saying that my account would be activated in a few days.  This was on
Oct. 21, and I have heard nothing since then.

I just figured that I didn't have enough clout for them to bother to
respond to me, but today on the www-buyinfo list, Stefan Brands, who
many think has the best ecash technology available today, posted that he
had had the same experience!  Brands himself has still not been given
an opportunity to join the beta test.  He did not sound very happy about
this.

I can see that Chaum and Brands are potential competitors to an extent;
they both have or will soon have patents which will be necessary for
efficient offline systems.  But it is clear to me that some form of cross
licensing is going to be necessary to have a really clear patent situation.
Under the circumstances it seems silly for Chaum to antagonize such an
important player in the game.

Of course, it may well be a matter of incompetence rather than insult,
but the net result is the same.  The more I see of digicash's lack of
consideration towards their potential customers and important figures like
Brands the more I question whether they have the potential to succeed.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLt35LhnMLJtOy9MBAQEyPwIA7gDKNK7T+vCp1I+YnUrsDb1sDhTWFO4T
olTEgTZnLtbQMLe70bNni2jjL0SShFqHRpSNZbsEPt0UAdmf5Pcf+A==
=MZXU
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

I'm going to tie together two threads on ecash: one here (Hal and
Rishab have both mentioned the ecash system test recently) and one
from www-buyinfo about scalability. If you dislike ecash, hit 'n' now

I'm running one of the prototype shops
(http://www.iquest.com/~fairgate), so let me chime in with my e$0.02
of comments. (no, that doesn't mean I'll pay you e$0.02 to read them!)

Hal said:
> I just figured that I didn't have enough clout for them to bother to
> respond to me, but today on the www-buyinfo list, Stefan Brands, who
> many think has the best ecash technology available today, posted that he
> had had the same experience!  Brands himself has still not been given
> an opportunity to join the beta test.  He did not sound very happy about
> this.

I was in the same boat-- I sent in several requests, all of which were
ignored. After Digicash issued a call for prototype shops, I signed
up. WHAM. I immediately started getting mail asking when I'd have my
shop ready-- sometimes two or three messages a day.

Once I got everything up and running, I didn't hear further from them.
Since then, an accident on my WWW server has rendered the e-shop
inoperable. I've asked Digicash, in the form of Paul Diniessen, for
help reconstructing the bank records. No go.

> Of course, it may well be a matter of incompetence rather than insult,
> but the net result is the same.  The more I see of digicash's lack of
> consideration towards their potential customers and important figures like
> Brands the more I question whether they have the potential to succeed.

The more I deal with Digicash, the better First Virtual looks. My
technical preference is for using Brands or Chaum cash; at present,
though, there aren't any shipping Brands servers, and the Digicash
folks don't seem to be able to get all their socks in one bag.

Digicash's system doesn't scale entirely cleanly, but it's Good Enough
if there's one central bank which all other banks can use, just as the
credit card companies have a central clearinghouse which allows my
credit union Visa to be used with merchants whose accounts are at
Citibank. 

The problems with Digicash thus far have been political and
business problems, not technical ones. As others have pointed out,
network bandwidth and processing CPU are cheap enough to allow
multiple banks to communicate cleanly. Real banks already understand
how to do this.

- -Paul

- -- 
Paul Robichaux, KD4JZG       | Good software engineering doesn't reduce the 
perobich@ingr.com            | amount of work you put into a product; it just 
Not speaking for Intergraph. | redistributes it differently.
		  ### http://www.intergraph.com ###

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLt44Xafb4pLe9tolAQH4AgP/U93rIqM73vBYb/wByCjfBDENuYKTSRe4
C4sRzMt6mgFqs/RSeTczA4x8CZi/ytVw5zjN4ApWuWC9BZpnSrHjBxls/pwRwhGB
2OrViy5jVYtlJ+v78JemsZhiKqOBU2bZ0TDWYVmSKcvWN20fG3fri77lKrpMpYT1
feNB7+T+Q1w=
=SZ9T
-----END PGP SIGNATURE-----

paul@poboy.b17c.ingr.com (Paul Robichaux) writes:
[digicash stuff...]
At some point I am going to have to take a look at my NDA with Digicash
again and see how much I can say about the reality of some of these
things... 
>
> As others have pointed out,
> network bandwidth and processing CPU are cheap enough to allow
> multiple banks to communicate cleanly. Real banks already understand
> how to do this.

Wanna bet?  You should get into a clearing discussion with Eric sometime (I
think that the clearing issue must be one of his favorite things in the
world as he has so much to say about it :)  Clearing is not only
non-trivial, it can be downright ugly.  A small system is not incredibly
difficult to set up, but a nationwide or global system would be something
that would give scores of engineers and designers nightmares for years to
come.  Things are easy when you talk about your $50 Visa purchase or check,
but when you start to deal with clearing big aggregate sums through banks
things get real nasty very quickly.

In the US we have the Fedwire system and other gifts of the Federal Reserve
to prop up a few of the weakest parts of the problem, but it is still a
house of cards waiting for the right puff of wind...

jim

-----BEGIN PGP SIGNED MESSAGE-----

> paul@poboy.b17c.ingr.com (Paul Robichaux) writes:
> [digicash stuff...]
> At some point I am going to have to take a look at my NDA with Digicash
> again and see how much I can say about the reality of some of these
> things... 

I've asked them to say something. The best I could get out of Paul
Dineissen is that they're talking with banks. Well, duh. The _present_
reality is that I can sell things ** and get paid ** if I use First
Virtual, but not if I use ecash.

> >
> > As others have pointed out,
> > network bandwidth and processing CPU are cheap enough to allow
> > multiple banks to communicate cleanly. Real banks already understand
> > how to do this.

> Wanna bet?  You should get into a clearing discussion with Eric sometime (I
> think that the clearing issue must be one of his favorite things in the
> world as he has so much to say about it :)  Clearing is not only
> non-trivial, it can be downright ugly.  A small system is not incredibly
> difficult to set up, but a nationwide or global system would be something
> that would give scores of engineers and designers nightmares for years to
> come.  Things are easy when you talk about your $50 Visa purchase or check,
> but when you start to deal with clearing big aggregate sums through banks
> things get real nasty very quickly.

Why clear big aggregate sums? Why not just clear smaller ones? Hell,
why not use a forwarding engine that just says "this cash came from
bank X" and sends it along?

I'm sure that the design of a robust, usable system is nontrivial, and
I don't mean to imply that it is. I just don't believe that a tool the
size of Fedwire and the existing bank architectures are, or will be, required.

- -Paul

- -- 
Paul Robichaux, KD4JZG       | Good software engineering doesn't reduce the 
perobich@ingr.com            | amount of work you put into a product; it just 
Not speaking for Intergraph. | redistributes it differently.
		  ### http://www.intergraph.com ###

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLt5Hxqfb4pLe9tolAQGA0gQAgd8BcSVu199NjEx3uMq4/ZrtaRA34z/g
X/VOMOIfUOuftj2wIiF5iVM5CMOoxMUz4J3gPESIOjZnVEtDUsfsD5aCtTuJW+39
Dmmjkm1nlTynDag7A0tsW39AfqGCpWy4gqcgwhHrvUvKt2Tts/XkvFwkT/wjLM0f
3reNbfPMSZY=
=y4mZ
-----END PGP SIGNATURE-----

Paul Robichaux writes
> I'm sure that the design of a robust, usable [clearing] system 
> is nontrivial, and I don't mean to imply that it is. I just 
> don't believe that a tool the size of Fedwire and the existing 
> bank architectures are, or will be, required.

The tools will be vastly simpler and smaller than Fedwire, etc
but the system will be vastly larger an more complex than Fedwire
etc, because "the system" will consist of many diverse people
using these tools in diverse ways for diverse purposes.

Attempts to design an all encompassing well organized system
run counter to the way the internet works and are therefore
likely to fail. 

If it does not work by spontaneous order, it probably will not work.

Regrettably, there is an obvious conflict between full and true
anonymity, and spontaneous order.  On the other hand, absent
a centralized system, anonymity is less critical.

-- 
 ---------------------------------------------------------------------
We have the right to defend ourselves and our
property, because of the kind of animals that we        James A. Donald
are.  True law derives from this right, not from
the arbitrary power of the omnipotent state.            jamesd@acm.org

Paul Robichaux (perobich@ingr.com) writes:
> > Things are easy when you talk about your $50 Visa purchase or check,
> > but when you start to deal with clearing big aggregate sums through banks
> > things get real nasty very quickly.
> 
> Why clear big aggregate sums? Why not just clear smaller ones? Hell,
> why not use a forwarding engine that just says "this cash came from
> bank X" and sends it along?

I will defer to Eric on this one, but what happens is bank X does not seem
to respond?  What happens if bank X goes bankrupt between the time it says
"Yes that coin is good, pay user foo", and the time your bank goes to get
the money from bank X to settle it's payment to user foo?  Are you going to
clear every transaction individually, if so how much more will that cost
you than batching transactions?  What factors become involved when banks
start borrowing money to clear daily transactions among themselves?

Take a look at the process involved in clearing checks and you will soon
see how it can get very strange.

jim

Paul wrote:
> 
> I'm sure that the design of a robust, usable system is nontrivial, and
> I don't mean to imply that it is. I just don't believe that a tool the
> size of Fedwire and the existing bank architectures are, or will be, required.
> 

My $0.02:

The size or complexity of Fedwire is not the issue (it's actually
pretty simple compared to some off the suggestions I've heard
recently). Nor is this merely a matter of designing robust computer 
programs (although this is very important). What is important is the 
degree of trust between the clearing parties, the legal arrangements 
between the clearing parties, and the backend of the clearing mechanism,
which is settlement -- how you balance out the real money accounts.

Let's say you have two banks, X and Y. Bank X has slightly more
merchant activity than bank Y, as bank Y is more consumer oriented.
Therefore bank Y is going to receive more real dollars from its
customers, and bank X is going to pay out more real dollars to its
customers. If these two banks are part of the same clearing system, 
then it is certain that the net flow of e-cash from Y to X is going to 
need to be accompanied by a flow of real US$ from bank Y to bank X. 
This is called settlement.

In reality, these things are extremely dynamic, changing on a 
minute-by-minute basis throughout a clearing system, but let's
stick with this simple example. As Mr. Hughes pointed out recently, 
the question is not whether the system works when everything goes 
as expected, but rather what happens when things fail unexpectedly. 
For instance, if bank X has credited the accounts of its customers 
(the merchants) while waiting for bank Y to make an offsetting real 
cash transfer, and bank Y goes bankrupt (or is declared insolvent 
or whatever), then bank X is out that money.  

There are three possible solutions. One partial solution is to  
not treat e-cash as cash -- the balance does not become available 
at bank X until a settlement period has passed. At this point, 
you might as well stop calling it e-cash, and call it an e-check. It's 
still a non-trivial situation if the bank the check is written on goes 
belly-up, but there is less exposure to fraud, with an offsetting
nervousness on the part of the merchant that the e-check will bounce.

The second possibility is for all the clearing house members to 
trust some central entity to handle the clearing and insulate them
from the bankruptcy of the individual members. This is how
Fedwire works, and it is arguably simpler than various types of
peer-to-peer clearing systems, but requires a great deal of trust
in that central entity. It also could have more catastrophic
consequences in the event of the failure of that central entity.

The third is that X and Y belong to a clearing association. Banks
might settle deficit positions with one another (a 'net' system),
and could negotiate a certain deficit level with all others in
the system. If a deficit was exceeded during the clearing, a
partial settlement would be required from one member to another.
A variant on this is the 'net-net' system, where banks are allowed
a certain deficit position with respect to the clearing system as
a whole, and losses are shared according to some formula in the
event of a bankruptcy. Settlement is done by a bank's paying into (or
receiving from) the system according to its position at the end
of the settlement period. 

This doesn't sound too complex, until you start to read the relevant
parts of the Uniform Commercial Code. To paraphrase the docco for
the xterm source code, "If you think you understand this right 
away, you probably don't. It is a hideous mess." The question of
what should happen to e-cash caught in the flux of the bankruptcy 
of a member of an e-cash clearing association is not immediately
clear and is every bit as important a question as the specification
of the computer protocols. It involves careful contemplation of
the relevant law, carefully construted contractural arrangements,
and robust, well-written software. Note that it becomes almost
exponentially dicier when you try to scale it to an international
level (assuming you want to try to continue to work within the legal 
frameworks of the various countries, and probably even if you don't 
want to.)

Now, take bankruptcy, and replace it with "systematic fraud."
Suppose that the same fine type of folks who got involved in
S&Ls get into e-cash in a big way... the mind boggles.

I also have had no luck getting a beta client from digicash. I
"registered" through their WWW forms page, and got no response for
about a month. Then they sent me mail saying that they would be
sending a client, but that they were unrolling it in stages. That was
about a month ago. Perhaps this means I will get my client soon.

This does not speak well for digicash. If they were not ready to beta
their stuff, they should not have announced it. As it is, it makes
them look like a flake.

BTW, I am beginning to amass NexusBucks. I would _really_ like to buy
something with them, just to prove their viability. They are
exchangable 1-for-1 for US$, but only in terms of services on Sameer's
system. If anyone has a t-shirt or somehting similar that they'd like
to sell, please let me know.

Perhaps we should make the Cypherpunks motto a bit less ambitious.
Instead of "Cypherpunks write code," how about merely "Cypherpunks use
tools."

Raph