Re: Brands excluded from digicash beta

Hi,

We're sorry to hear any complaints about the handling of any requests for 
information regarding  ecash. As you can understand, we are certaintly not
planning to create unsatisied ecash users at the very start of the ecash endeavour.
So at least we are happy to hear from you so we can act appropriately.

DigiCash has the ambitious goal to make the ecash client 
software available on virtually every OS platform and/or system.
Alas, our programmers crew is not that extensive that we're able to 
release everything at once, we has to resort to a phased release 
approach.  For some insight in the release history of the sundry 
ecash versions, we refer to our WEB server pages.

With this background we answer your questions and remarks, at the hand of
some of quote orginating form your mail to DigiCash.  

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

As announced, the ecash-trial starts in phases. Currently we are 
completing most versions of ecash. We receive quite a lot of good 
feedback from the first releases. Therefore we decided to change the 
user-interface to get better software that is easier to use, before 
confronting the user of the next releases with problems already 
solved! 
We decided to first to select tester from our own timezone to 
facilitate easy voice communication in case extensive support issues. 
Contrary to our expectations we encountered  relatively  few 
problems, so we can  soon release also the beta-test to tester in the 
remaining time zones. 

So as you can see our release policy is not that staight forward and 
involves a lot of considerations like usability and acceptance.

This is one of the main reasons why Mr. S. Brands HAS received his 
beta-test version friday the 11th of November, together with all his 
collegues at the CWI.  They all run Silicon Graphics International OS 
and before that date this version wasn't finished.

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

Sometimes we can react very fast, but alas this is only the case for 
standard procedures which we did automate.  More specific questions 
and requests *have* to be handled by humans.  We think the people who are 
willing to invest quite some effort in setting up a shop for the beta 
test, are very important participants in the beta test trail.  
Therefore it seems *very* unlike to us that we didn't respond to *any*
mail or request from you.  Not trusting our own memory ( we do receive more 
than 100 (yes, hundred) mails on ecash *each* day, even Sundays) 
we dove right in to it and found a trail of  DigiCash answers to your mail 
with the subject: 'Concerns about ecash'.  

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

Sorry we *did* sent you a respons within an hour from your 
request by my colleague Branko. He is responsible for our bank in 
the trial. His respons was:

-The dbm library used by Linux and FreeBSD are different, so the ecash
-databases are also incompatible.  If you have a password for getting an
-initial balance, you can also use this password for reopening your
-account (and keeping your old balance).  For the server@fairgate.com
-account you can use the password ********  (pw made invisible PD) for this.
-
-Branko

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

We feel somewhat troubled by these comments.  We strongly feel that 
the alleged 'lack of consideration' as unjustified.  First we would 
like to split up your comment in to two different issues, first 
regarding our potential customers and secondly the issue of Mr. S. 
Brands.

As we mentioned before we deem *all* our users, in the past, now, and 
in the future, as important whether it concerns "shops"  or mere 
"customers"  they all contribute to a successful new payment medium.
We like you to consider this phase in the existence of ecash as a 
genuin beta trail.  In beta test not only software is being trailed 
but the supporting services too!  However, it should be noted that we 
did respond to your mail and requests. 

On the issue on Mr. S. Brands.  As we explained before no way we even 
considered to exclude Mr. Brands for the beta test. 

As of the technical appreciation of the Chaum system  as opposed to 
the Brands system and the alleged scalability issues , we propose you 
contact Mr. S. Brands and Mr. D. Chaum for details. 

We will give a call today to check if received this mail. We hope to 
resolve the problems mentioned above and to continue our co-operation.

Kindest regards,

Paul Dinnissen
DigiCash bv.

From: "Paul Dinnissen" <paul@digicash.com>

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

   We feel somewhat troubled by these comments.  

As well you should.

The facts of the matter is that First Virtual currently provides a net
benefit by moving real value (e.g. dollars) around, and Digicash does
not.  Until the Digicash system can move real value, there is no
reason to use it.

The technology is irrelevant.  _If_ you can move real value, you can
provide a benefit.  _Only if_ you can move real value can you provide
a benefit.

Eric

A further reply to Mr. Robichaux, who I paraphrase, "The more I 
have problems with the DigiCash beta, the better First Virutal
looks."

Some problems with this:

1) It is, after all, a Beta Test. Many companies limit 
   participation in such tests quite arbitrarily. Also,
   remember, DigiCash (to the best of my knowledge) is
   not going into the digital bank business itself, but
   rather through licensees. Aside from Paul, who is very
   PR oriented, it is primarily a group of quite talented
   young programmers who are, while answering your letters,
   trying to come out with new versions of the code. 
  
2) A group of us went over the First Virtual stuff in detail
   last night over fajitas, and were practically rolling on 
   the floor with laughter. Basically they have an attitude 
   of "Crypto is too hard, people won't want to use it." So
   instead, each transaction consists of an e-mail exchange
   which is converted ultimately into credit card transactions
   The exposure time for the merchant is on the order of _90 
   days_. All fraud, etc., is on the head of the merchant.

   The bottom line here is that FV has a system which is
   much more sluggish than the DigiCash system, even though
   it doesn't use "hard" crypto. It is far from anonymous, and
   the transactions are trivially reversible. This is actually
   a _design goal_ in their "Soylent Green", er, "Simple Green"
   proposed standard. It is completely inappropriate for hard
   goods of significant value, and its minimum transaction cost
   is high enough to rule out its applicability for very small
   transactions. Even if used for purely informational goods,
   if an undercapitalized info service becomes popular, it will
   sink beneath the waves while waiting for payment.

   As near as I can tell, FV's technology was developed by people
   who wanted to implement their pet philosophy about Internet 
   commerce (customer should examine info first, then commit to 
   paying, all transactions reversible, cryptography and anonymity 
   are bad, secure transactions are not possible on the net, etc.),
   rather than anything bordering on an Internet cash-like system.

   So, I ask, First Virtual is looking better and better for doing
   _what_?  Until they deal with the interface problem (get a decent
   client, rather than relying exclusively on e-mail), I think 
   they're not even going to be adequate for getting shareware-scale
   proceeds from putting up a cool Web page.

Doug Barnes writes
> 1) It is, after all, a Beta Test. Many companies limit 
>    participation in such tests quite arbitrarily. Also,
>    remember,

So send out a form letter:

   "Thank you for your interest.  At the moment we are not
    seeking beta testers with your kind of hardware.   We
    will contact you when when further news happens.
   "

I have applied three times, and received no response
whatever.

If you cannot manage a form letter, your business is unlikely
to go anywhere.   Sell or lease the patents to someone who
can manage a mailing list.

>    So, I ask, First Virtual is looking better and better for doing
>    _what_? 

For answering their mail.  For acting in accordance with their
business plan.  For moving money from point A to point B.

Ninety percent of success is showing up on time.


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

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

> A further reply to Mr. Robichaux, who I paraphrase, "The more I 
> have problems with the DigiCash beta, the better First Virutal
> looks."

Doug, you must be talking to my dad; he's Mr. Robichaux. Having
inadvertently offended the Digicash people in my previous message, let
me see if I can give equal time to what's wrong with FV in this
message.

> Some problems with this:

> 1) It is, after all, a Beta Test. Many companies limit 
>    participation in such tests quite arbitrarily. Also,
>    remember, DigiCash (to the best of my knowledge) is
>    not going into the digital bank business itself, but
>    rather through licensees. Aside from Paul, who is very
>    PR oriented, it is primarily a group of quite talented
>    young programmers who are, while answering your letters,
>    trying to come out with new versions of the code. 

Maybe it's just me. As a beta-shop owner, I expect to have Digicash
work with me when I have problems, concerns, or questions. Marcel,
Paul, and others at Digicash were very helpful during the incubation
period. My chief concern at this point is that there's no way for me
to get paid, and no publicly available date for same.

I didn't suggest that Stefan Brands, or anyone else, was being denied
access to the trial. I have no evidence to suggest any explanation for
his complaint, Hal Finney's, or mine-- other than that the Digicash
folks are very, very busy.

> 2) A group of us went over the First Virtual stuff in detail
>    last night over fajitas, and were practically rolling on 
>    the floor with laughter. Basically they have an attitude 
>    of "Crypto is too hard, people won't want to use it." So
>    instead, each transaction consists of an e-mail exchange
>    which is converted ultimately into credit card transactions
>    The exposure time for the merchant is on the order of _90 
>    days_. All fraud, etc., is on the head of the merchant.

I think their attitude is that crypto's not _necessary_. I disagree;
Nathaniel Borenstein has already been taken to task on www-buyinfo for
that view. Their API supports TCP/IP transactions, so the mail
exchange is between the FV server and the buyer.

The very fact that FV has a set of terms and conditions that mention
exposure time, responsibility for fraud, and so on tells me that their
system is more fully fielded. I know, I know; ecash is in beta. That's
fine. I still want to be able to sell things _now_.

>    The bottom line here is that FV has a system which is
>    much more sluggish than the DigiCash system, even though
>    it doesn't use "hard" crypto. It is far from anonymous, and
>    the transactions are trivially reversible. This is actually
>    a _design goal_ in their "Soylent Green", er, "Simple Green"
>    proposed standard. It is completely inappropriate for hard
>    goods of significant value, and its minimum transaction cost
>    is high enough to rule out its applicability for very small
>    transactions. Even if used for purely informational goods,
>    if an undercapitalized info service becomes popular, it will
>    sink beneath the waves while waiting for payment.

All of the above is true. You can't use FV for hard goods, the minimum
transaction cost rules out microtransactions, and the payment hang
time is too long. 

On the other hand, I can't use ecash for hard goods. I have no idea
what the transaction costs will be, and there's no way for sellers to
get paid _at all_.

>    As near as I can tell, FV's technology was developed by people
>    who wanted to implement their pet philosophy about Internet 
>    commerce (customer should examine info first, then commit to 
>    paying, all transactions reversible, cryptography and anonymity 
>    are bad, secure transactions are not possible on the net, etc.),
>    rather than anything bordering on an Internet cash-like system.

You're right here, too. I happen to agree with the portion about
allowing try-before-you-buy access; in some cases that is a very
valuable way to gain market and mindshare. Remember the "Macintosh
Test Drive" in 1985?

>    So, I ask, First Virtual is looking better and better for doing
>    _what_?  Until they deal with the interface problem (get a decent
>    client, rather than relying exclusively on e-mail), I think 
>    they're not even going to be adequate for getting shareware-scale
>    proceeds from putting up a cool Web page.

Not. Read their web pages. There's a TCP/IP API, which I'm using. The
only mail exchange is from the FV server to the customer and back
again. As Hal pointed out, there are valid reasons to support systems
other than the Digicash e-wallet. After all, there will be offline
ecash, right?

First Virtual's chief advantage is that I can get paid. No fooling
with clearing, scalability, or anything else-- people can buy my
products.

- -Paul Robichaux

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

iQCVAwUBLt9NY6fb4pLe9tolAQFYgAP8C5KfpLyvpqv5KVEquMKIKC+HOgWcOLKt
dCc5sW55toRwrNBihALPFy4p40Fi8uZclIUgcNTyICnogof0WzSAnkAv+GRq8Ear
ePuqqEQX0N1iWFaLlvIxVt4ALrtic4lE8O4GhE/xEl2ecBz5UR6haieGJDAhW4k4
kJZTMyAgKNI=
=nDr0
-----END PGP SIGNATURE-----

> 
> Maybe it's just me. As a beta-shop owner, I expect to have Digicash
> work with me when I have problems, concerns, or questions. Marcel,
> Paul, and others at Digicash were very helpful during the incubation
> period. My chief concern at this point is that there's no way for me
> to get paid, and no publicly available date for same.

There have clearly been problems in communication and in 
expectation-setting. In particular, since DigiCash is not,
to the best of my knowledge, planning on entering the 
US$ cash <--> ecash business themselves (instead, using
licensees), it might have been a wise move for them to set 
expectations lower or to have taken steps to guarrantee at 
least a trial US$ cash <--> ecash gateway.

> I think their attitude is that crypto's not _necessary_. I disagree;
> Nathaniel Borenstein has already been taken to task on www-buyinfo for
> that view. Their API supports TCP/IP transactions, so the mail
> exchange is between the FV server and the buyer.

If you've used the DigiCash clients, you know that they make it
much, much easier to spend money than this e-mail confirmation
system. Since they don't use crypto (and instead rely on the
debatable assumption than an e-mail backchannel is secure, backed
up by extreme reversability). This is not to say that someone
couldn't remedy these problems along the same lines as DigiCash
without using blind signatures or licensing from Chaum, however.

> 
> The very fact that FV has a set of terms and conditions that mention
> exposure time, responsibility for fraud, and so on tells me that their
> system is more fully fielded. I know, I know; ecash is in beta. That's
> fine. I still want to be able to sell things _now_.
> 

FV may be more operational, although I'm curious if any transactions 
have managed to fully settle yet... yes, it is important for the operator 
of a US$ cash->ecash gateway to consider fraud and exposure, but the 
_protocol_ determines that e-cash transactions are non-reversible, like
putting coins into a vending machine. The gateway operator has to either
use non-reversible US$ inputs, or needs to determine an acceptable level
of exposure to reversible transactions.

The two systems are worlds apart in terms of where the risk is placed.
FV places the risk entirely on the vendor; DigiCash places the risk
entirely on the e-cash holder. Note that lots of people walk around with
credit cards, bills _and_ coins in their wallets, and use them for different 
things throughout the day. I don't think that things are going to be
that different on the net.

> On the other hand, I can't use ecash for hard goods. I have no idea
> what the transaction costs will be, and there's no way for sellers to
> get paid _at all_.

This is absolutely true, and will remain so until at least one
of Chaum's licensees becomes operational. 

> I happen to agree with the portion about
> allowing try-before-you-buy access; in some cases that is a very
> valuable way to gain market and mindshare. Remember the "Macintosh
> Test Drive" in 1985?

I think that if people want try before you buy, it can be done
(easily) without building it into the payment protocol. I'm 
all for shareware, giving freebies so folks get hooked, and
so forth, but it seems odd to build a unconditional rejection into
the payment system, especially for products that can't be
returned in any meaningful sense.

> Not. Read their web pages. There's a TCP/IP API, which I'm using. The
> only mail exchange is from the FV server to the customer and back
> again. As Hal pointed out, there are valid reasons to support systems
> other than the Digicash e-wallet. After all, there will be offline
> ecash, right?

I think that it is _vital_ to have e-mail and TCP/IP versions, 
don't get me wrong here! I _have_ read the web pages, and I
note that you still have to pop into your e-mail to approve the
purchase. This is an inherent flaw to the protocol, that there 
will be 2-3 user-side software components, instead of 1-2 with
DigiCash:

FV: browsing software, paying software, confirming software
DC: browsing software, full payment software

I'm assuming that over time, the TCP/IP payment methods will be
integrated into browsing software, but FV will always be hampered
by the need to have something separate to handle the back-channel,
since they are religiously opposed to using signatures for 
validation (although you suggest some progress in this area).

> 
> First Virtual's chief advantage is that I can get paid. No fooling
> with clearing, scalability, or anything else-- people can buy my
> products.
> 

You get paid (in ninety days), so great, use it today if you can
get your users to use it. Keep your eyes open for tomorrow. 
You may end up getting actually paid by another method before the
payments you receive today actually settle...

I'm sorry that it took me so long to reply to this thread.  I've been
travelling and came back to a backlog of over 3000 messages.  (The 100
messages/day reported by the Digicash folks sounds really *pleasant* to
me right now -- I'm averaging around 350!  :-) )

Excerpts from fv: 2-Dec-94 Re: Brands excluded from di.. db@Tadpole.COM (2508*)

> 2) A group of us went over the First Virtual stuff in detail
>    last night over fajitas, and were practically rolling on 
   the floor with laughter.

I'm delighted to hear that you're so easily amused.  I hope your
merriment wasn't too disruptive to the other diners, who might have
drawn the mistaken conclusion that you were either rude, foolish, or
both.

>  Basically they have an attitude 
>    of "Crypto is too hard, people won't want to use it." So
>    instead, each transaction consists of an e-mail exchange
>    which is converted ultimately into credit card transactions

Wrong.  A First Virtual transaction takes place as a single step via
mail, FTP, or WWW.  *After* the transaction there is an email exchange
to confirm the purchase, and although this exchange works as-is with
virtually any mail reader in the world, it can be largely automated by
an FV-enhanced mail reader.  Ultimately, using such a tool you'll be
able click on a single button to confirm ALL of your recent
transactions, assuming they're all ones you want to authorize.

>    The exposure time for the merchant is on the order of _90 
>    days_. All fraud, etc., is on the head of the merchant.

You're right about the 90 days for now;  as I have stated many times,
this is an inevitable consequence of our extending the credit card
merchant system to unknown and untrusted sellers anywhere on the
Internet.  You can become an FV seller with no credit checks, and indeed
with no human intervention, so the 90 days protects us (and by extension
the community of legitimate buyers and sellers) against abusive sellers.
 As I have also stated, however, we are working on a system whereby
legitimate sellers can go through a qualification process after which
the 90 day holding period will be completely waived.  We cannot yet
announce a definite availability date for this facility, but it isn't
very far away.

>    The bottom line here is that FV has a system which is
>    much more sluggish than the DigiCash system, even though
>    it doesn't use "hard" crypto. 

Well, it doesn't use "any" crypto, hard or soft.  As to "sluggish" -- I
would point out that you can set yourself up with an account in minutes,
without human intervention, which contrasts pretty well with some of the
experiences reported on this list with other systems.  And purchases are
instantaneous.  What's sluggish?  Have you actually tried using our
system?

It is far from anonymous, 

This depends on your definition of anonymity.  In our system, a buyer
and a seller can meet and conduct business without EVER knowing each
other's identities unless they choose to reveal them.  This is trivial,
and indeed it already happens all the time on our Infohaus.  However,
First Virtual knows the real identities (or, at least, we know the real
underlying credit card, from which the real identity can be ultimately
traced), and can be forced to provide it to the government under court
order.  We will otherwise keep all such information completely private. 
I think this meets most practical standards for anonymity, and it is
certainly far more anonymous than most real-world commerce mechanisms
such as credit cards, where they buyer & seller names both appear on the
charge slip.

> and the transactions are trivially reversible. This is actually
>    a _design goal_ in their "Soylent Green", er, "Simple Green"
   proposed standard. 

I'm not sure what you're referring to here, but if you mean that it's
possible to refund someone's money, that's certainly true.  All our
accounts are in principle bidirectional, although people can choose to
have buyer-only or seller-only accounts.

Just out of curiousity, if I think of a silly name to call someone
else's commerce mechanism, will that prove anything of interest?

> It is completely inappropriate for hard
>    goods of significant value, 

As we have made clear, this was an explicit design decision.  Our terms
and conditions, which you don't seem to have read, actually FORBID the
use of our commerce engine for hard goods.  So you really don't need to
work too hard to convince us on this point.

> and its minimum transaction cost
>    is high enough to rule out its applicability for very small
>    transactions. 

Wrong again.  We explicitly permit seller-based accumulation, so there's
nothing to stop you from building a service that charges, say, a tenth
of a penny for each bit of information; however, you have to accumulate
the charges on your end until they pass our 30 cent threshhold, that's
all.  If someone buys less than 30 cents worth of stuff from you, you
have to take it as a "free sample" loss.

> Even if used for purely informational goods,
>    if an undercapitalized info service becomes popular, it will
>    sink beneath the waves while waiting for payment.

This is amazingly wrong.  First of all, consider what it means for an
info service to become popular:  It means that their server and net
connection are more highly utilized.  Neither of these is typically a
metered resource, which means the incremental costs are zero.  There's
an incremental cost involved in upgrading either of them, but if your
service is so wildly successful that you have this problem, how hard do
you think it will be for you to get a bank loan to cover an upgrade to
your computing facilities or Internet connection, which are the ONLY
incremental costs of this kind of runaway success?

It is also worth noting that in the existing credit card system, new
merchants who have only recently qualified for Visa/MC merchant status
often have a similar holding period imposed upon them by their banks. 
It's Standard Operating Procedure, that's all.  If you're setting up an
information service based on our mechanism, the cost of operation for
the first 90 days should be factored into your startup expenses, just
the way you would have to factor in the cost of inventory for a
hard-goods business.  (Indeed, for most hard goods businesses, the
inventory cost would be higher  than 90 days operating expenses.)

>    As near as I can tell, FV's technology was developed by people
>    who wanted to implement their pet philosophy about Internet 
>    commerce (customer should examine info first, then commit to 
>    paying, all transactions reversible, cryptography and anonymity 
>    are bad, secure transactions are not possible on the net, etc.),
>    rather than anything bordering on an Internet cash-like system.

Wrong again.  FV's technology was developed by people who wanted to sell
information products on the Internet.  That's the ONLY reason we did it.
 We didn't (and still don't) see any other commerce mechanism that would
meet our needs, so we built one.  We expect to make our money on
information products, not on the commerce engine.

We also don't think cryptography and anonymity are bad.  If you would
just read our materials, you will see that we think that cryptography is
problematic and that anonymity is good.  We've strived for the maximum
possible anonymity without the problems we perceive in using
cryptography.  (And FYI, we know whereof we speak: we use cryptography
heavily internally, and we are extremely aware both of its power and
utility AND of the practical difficulties in its use.)

>    So, I ask, First Virtual is looking better and better for doing
>    _what_?  Until they deal with the interface problem (get a decent
>    client, rather than relying exclusively on e-mail), I think 
>    they're not even going to be adequate for getting shareware-scale
>    proceeds from putting up a cool Web page.

Please check out our Web pages before you make any more comments like
this one.  You can buy stuff today from our Infohaus, using Web or FTP
access, or email if you prefer, so it's pretty silly to say that we rely
exclusively on email.  (Actually, the email interface is the LEAST
usable.)  The people selling things on our Infohaus -- who are NOT
associated with FV in any way other than as our customers -- get paid in
REAL MONEY.  Tell *them* that the system isn't adequate.  Or tell it to
my in-laws, who are now getting monthly loan repayments (real money)
from me via a cron job that I set up on my own machine at home  (Setting
up such a job requires no special FV intervention -- anyone who knows
how to set up a cron job can do it, it's that easy.  This stuff really
works, check it out!)

> FV may be more operational, although I'm curious if any transactions 
have managed to fully settle yet... 

We haven't been up for 90 days yet, so no funds have passed the aging
period.  I'll suggest to our PR people that they make a big deal about
the first settlement to sellers, which should happen in January...

> The two systems are worlds apart in terms of where the risk is placed.
> FV places the risk entirely on the vendor; DigiCash places the risk
> entirely on the e-cash holder. Note that lots of people walk around with
> credit cards, bills _and_ coins in their wallets, and use them for different 
> things throughout the day. I don't think that things are going to be
> that different on the net.

Hey, we agree on something!  Different mechanisms for different purposes
makes perfect sense.  This is why you won't, in general, find us
bad-mouthing any of the other systems -- we think there's room for
several payment mechanisms on the net, and don't see any purpose being
served by "taking the low road".  I'm happy to note that the folks
behind the other systems seem to be taking a similar approach.  I hope
we can all keep it up.

> I think that if people want try before you buy, it can be done
> (easily) without building it into the payment protocol. I'm 
> all for shareware, giving freebies so folks get hooked, and
> so forth, but it seems odd to build a unconditional rejection into
> the payment system, especially for products that can't be
> returned in any meaningful sense.

Of course it can be done without bundling it into the payment protocol. 
You've missed a critical point:   By "bundling" it into the payment
protocol, we have been able to achieve a vast SIMPLIFICATION of the
payment protocol.  It is not a coincidence that we are the first (and so
far, still the only) system that is operational with real money.  It's
because we set out to implement that subset of commerce that was
amenable to rapid deployment.  Try-before-you-buy permits a vastly
simplified commerce system, but nobody should be surprised if that
commerce system is ONLY useful in situations where try-before-you-buy is
acceptable!

> don't get me wrong here! I _have_ read the web pages, and I
> note that you still have to pop into your e-mail to approve the
> purchase. This is an inherent flaw to the protocol, that there 
> will be 2-3 user-side software components, instead of 1-2 with
> DigiCash:

You've read them, but you don't appear to have understood them, which is
probably our fault, not yours.  The email confirmation is indeed a bit
cumbersome if it gets invoked very often and your mail system isn't
FV-smartened.  But if you use an FV-smart mail tool -- and note that
Z-code recently became the first vendor to publicly announce and
demonstrate support for our protocols -- you can get this down to where
a single mouse click authorizes a dozen or so purchases.  Not a big
deal.  You could even have an intelligent agent do the authorization for
you in some cases, although this requires some real caution!

> I'm assuming that over time, the TCP/IP payment methods will be
> integrated into browsing software, but FV will always be hampered
> by the need to have something separate to handle the back-channel,
> since they are religiously opposed to using signatures for 
> validation (although you suggest some progress in this area).

You can already browse by Web or FTP, so "over time" == "now".

Once again, we're not OPPOSED (religiously or otherwise) to using
digital signatures, we're just opposed to making electronic commerce
wait for the widespread deployment of signature technologies.  When such
technologies are widely deployed, we'll probably use them (though this
is not a promise, it will depend on the situation at the time).

Sorry for the length of this message -- I hope it clears up a few
misconceptions.  -- Nathaniel

PS -- Doug, please tell the folks at Tadpole that your mailer is not
doing a very good job generating Message-ID headers.  In particular, it
isn't getting the domain right in the Message-ID, which can be a problem
for Message-ID uniqueness.  Specifically, instead of
<9412021548.AA17294@tadpole> it should really be
<9412021548.AA17294@tadpole.com>  It's just a nit, but these little
details do matter, and if you tell me what mail tool you're using, I
might be able to tell you how to fix it.  -- NB

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

In article <UivSTnb0Eyt5NcCs4x@nsb.fv.com>,
Nathaniel Borenstein <nsb@nsb.fv.com> wrote in the middle of his novel:
>It is not a coincidence that we are the first (and so
> far, still the only) system that is operational with real money.

Why do you keep claiming this?  It wins you no points in this forum:
people know better.

Bibliobytes/HKS' system has been in operation since June, processesing
orders for soft matter.  NetMarket's system has been on-line and
working since August, taking orders for CDs and flowers.  Etc,
etc...
- -- 
Todd Masco     | "'When _I_ use a word,' Humpty-Dumpty said, in a rather
cactus@hks.net |  scornful tone, 'it means just what I choose it to mean -
cactus@bb.com  |  neither more nor less.'"   - Lewis Carroll
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLu5bvSoZzwIn1bdtAQFpsQGAy+fPx09OYW7TGKpqYrX+KtmjakvDnPie
SZhiKZLvV/oPV/FITSaDWlb9qb/H5IX+
=vakz
-----END PGP SIGNATURE-----

From: nsb@nsb.fv.com

   Wrong.  A First Virtual transaction takes place as a single step via
   mail, FTP, or WWW.  *After* the transaction there is an email exchange
   to confirm the purchase [...]

If this email exchange is necessary and not merely advisory, then it's
part of the transaction, unless you have a far different notion of
transaction than I do.

   This depends on your definition of anonymity.  

There are two forms of anonymity: counterparty anonymity and issuer
anonymity.  FV claims the first but not the second.  "Far from
anonymous" may be a little confusing, but it's certainly far from
completely anonymous.

   I think this meets most practical standards for anonymity, [...]

That depends on your standards, I suppose.  It's certainly not
sufficient for anonymous mail with digital postage.

   > and its minimum transaction cost
   >    is high enough to rule out its applicability for very small
   >    transactions. 

   Wrong again.  We explicitly permit seller-based accumulation, [...]

Net clearing of this form requires the creation of an entire billing
system for small value which then settles through FV.  The very nature
of such a net billing system requires linkability of transaction to
transaction, or in other words generates identity.  So FV is
unsuitable for small value anonymous transactions.

   We expect to make our money on
   information products, not on the commerce engine.

At 29 cents plus 4% per settlement transaction, I find this comment
disingenuous in the extreme, even after paying Visa for settlement.

   > it seems odd to build a unconditional rejection into
   > the payment system, especially for products that can't be
   > returned in any meaningful sense.

   Of course it can be done without bundling it into the payment protocol. 

But, I suspect, it can't be done if you want to piggyback on Visa's
settlement system.

   By "bundling" it into the payment
   protocol, we have been able to achieve a vast SIMPLIFICATION of the
   payment protocol.

You haven't simplified the protocol, you've simplified your business
model.

   It is not a coincidence that we are the first (and so
   far, still the only) system that is operational with real money.  

I question "first".  Certainly one of the first.

In any case,, it isn't a coincidence that you were able to start up
quickly, because you didn't build a settlement system for real value
but rather used someone else's.

   [... earlier in the post ...]

   (And FYI, we know whereof we speak: we use cryptography
   heavily internally, and we are extremely aware both of its power and
   utility AND of the practical difficulties in its use.)

   [... then later ...]

   The email confirmation is indeed a bit
   cumbersome if it gets invoked very often and your mail system isn't
   FV-smartened.

So if you're planning on removing the cumbersomeness of your current
protocol with software, why is it that you don't have an option to
turn on crypto, whose cumbersomeness can also be mitigated with
software?

This position seems, well, inconsistent.
 
Eric

Excerpts from fv: 14-Dec-94 properties of FV eric@remailer.net (3093)

> There are two forms of anonymity: counterparty anonymity and issuer
> anonymity.  FV claims the first but not the second.  "Far from
> anonymous" may be a little confusing, but it's certainly far from
> completely anonymous.

Thanks for introducing the useful terminology.  You're right, FV
provides counterparty anonymity but not issuer anonymity.  A useful
clarification.

>    Wrong again.  We explicitly permit seller-based accumulation, [...]

> Net clearing of this form requires the creation of an entire billing
> system for small value which then settles through FV.  The very nature
> of such a net billing system requires linkability of transaction to
> transaction, or in other words generates identity.  So FV is
> unsuitable for small value anonymous transactions.

No, it doesn't require an entire billing system, because it lives
entirely on the seller's machine and does nothing except the pre-billing
accumulation for a single seller.  It requires a simple database and a
nightly cron job.  The next time I have a day or two free I will
probably build such a thing and add it to the free FV software; I don't
expect it will be more than a day or two's work, if that.

>    We expect to make our money on
>    information products, not on the commerce engine.

> At 29 cents plus 4% per settlement transaction, I find this comment
> disingenuous in the extreme, even after paying Visa for settlement.

Well, at 29+4% it would indeed be disingenious.  However, that's not
what we're charging -- I'd encourage you to actually read our materials.
 We're charging 29 cents plus 2%, and this includes all the charges to
the credit card networks, the banks, and our financial transaction
processors.  We are NOT operating on a big margin here.

> So if you're planning on removing the cumbersomeness of your current
> protocol with software, why is it that you don't have an option to
> turn on crypto, whose cumbersomeness can also be mitigated with
> software?

As I said in an earlier post this morning, this *is* an option we will
probably support eventually, although I don't think it is as easy to
make crypto easy-to-use as it is to make checkboxes easy-to-use, at
least not without deeply compromising the security of the crypto system.
 Mostly, however,, we just think that it's a longer-term problem,
because we see the widespread deployment of crypto as being a
longer-term phenomenon.  -- Nathaniel

> Net clearing of this form requires the creation of an entire billing
   > system for small value which then settles through FV.  

   No, it doesn't require an entire billing system, because it lives
   entirely on the seller's machine and does nothing except the pre-billing
   accumulation for a single seller.

Just because it's all on one machine doesn't make it not a billing
system.  If it does "nothing except pre-billing", then it doesn't
have the ability to tie into FV.

Such an "accumulation system" has all the properties of a standard
billing system.  It has accounts with accumulate claims, it
periodically asks the customer to pay off liabilities, and it must
check that payment has actually been made.

Just because the values are small, the process is partially automated,
and it all happens much quick does not prevent it from being a billing
system.  Personally, I'd call it a receivables system, because that's
much closer to existing terminology for the actual accounting function.

I'm not trying to imply that you couldn't cobble something up fairly
quickly, but I have my doubts that a good quick hack will scale
appropriately for even a modest sized operation.

   > The very nature
   > of such a net billing system requires linkability of transaction to
   > transaction, or in other words generates identity.  So FV is
   > unsuitable for small value anonymous transactions.

I would still like to you address this issue, if only to acknowledge
the above characterization.

   > At 29 cents plus 4% per settlement transaction, I find this comment
   > disingenuous in the extreme, even after paying Visa for settlement.

   We're charging 29 cents plus 2%, and this includes all the charges to
   the credit card networks, the banks, and our financial transaction
   processors.  We are NOT operating on a big margin here.

As I had recalled from reading your materials, you were charging 29
cents plus 2% on one leg of the transaction plus an additional 2% on
the other.  Rereading, this is not the case.  Am I remembering a
previous situation?

   As I said in an earlier post this morning, this *is* an option we will
   probably support eventually, although I don't think it is as easy to
   make crypto easy-to-use as it is to make checkboxes easy-to-use, at
   least not without deeply compromising the security of the crypto system.

Partial security is better than no security.

Deep compromises only happen if your expectations of the crypto system
are larger than deserved.  If all you expect is a partial solution,
other aspects of the cryptography fall away.  Just because crypto
_can_ do more than one might use it for is no argument for getting
_some_ benefit out of it.

You've not seen this recently on cypherpunks, but I've been stressing
recently the need to deploy partial solutions.  Roughly speaking,
crypto is good for transit security and storage security.  The primary
security problem with FV is transit security, not storage security.
This is a known solved problem.

There are issue of security of private keys stored on Internet
machines.  Were possession of such a key required in order to crack
the system, however, it would be _in addition_ to everything else
already required.  To mitigate key storage risk I would recommend a
key generated entirely and only for use with FV.

One of the underlying conceptual problems with allowing a key to be at
risk is some sort of belief that compromises of secret keys should
never ever EVER be allowed to happen.  This is ludicrous.  When the
benefit of the use of a private key means that it might be
compromised, don't rely upon it's not being compromised.

In particular, if a digital signature does not, by agreement, carry an
implied warrantee of identity, then there's no problem at all.  Use
the crypto entirely for transit security.  If someone hacks your
machine and grabs your passphrase and forges a transaction, at least
the intruder has to grab your passphrase.

Eric

| We're sorry to hear any complaints about the handling of any requests for 
| information regarding  ecash. As you can understand, we are certaintly not
| planning to create unsatisied ecash users at the very start of the ecash endeavour.

But, for the most part out here, we can't tell.  I, too, have heard only
deafening silence from e-cash folks in response to my multiple queries and
requests for more information on their system, let alone joining their beta
test.  Like Hal Finney, I just assumed I was being ignored because I didn't
have enough clout.  As a result, I just gave up on e-cash as something I
wouldn't find useful any time soon.

I do understand the difficulties in dealing with releases on multiple
platforms.  Still, you might at least acknowledge e-mail from people who
want to help make your system work, who want to use it.  A form letter at
least, explaining that you don't need their help right at the moment but
will let them know when a system for their platform is being released for
a wider beta test, well, that might be a real good idea.  Ignoring people
after you've publicly asked for beta testers and said "mail to <...> for
further information" is definitely not a good idea.

My count:  4 messages over about 6 months asking for more info, no replies.
My reaction:  Well, it was a nice idea.  Maybe I'll check back in a couple
of years, when there might actually be someone there.


Rich

PS - I'm not posting this to two lists because I've seen that's the only
way to squeeze a response out of DigiCash, but you can be forgiven for
thinking things like that. ;-)

-- 
Loudyellnet: Richard Johnson | Sneakernet: ECNT1-6, CB 429, CU Boulder
Phonenet:    +1.303.492.0590 | Internet:   Richard.Johnson@Colorado.EDU
   RIPEM and PGP public keys available by server, finger or request
   Speaker to avalanche dragons.   Do you really think they listen?

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

Paul, 

I appreciate your reply, especially the information that I can use to
reconstruct my account. I never received the mail that Branko
originally sent. Evidently no one received my repeated requests sent
after the first one.

> Sometimes we can react very fast, but alas this is only the case for 
> standard procedures which we did automate.  More specific questions 
> and requests *have* to be handled by humans.  We think the people who are 
> willing to invest quite some effort in setting up a shop for the beta 
> test, are very important participants in the beta test trail.  
> Therefore it seems *very* unlike to us that we didn't respond to *any*
> mail or request from you.  Not trusting our own memory ( we do receive more 
> than 100 (yes, hundred) mails on ecash *each* day, even Sundays) 
> we dove right in to it and found a trail of  DigiCash answers to your mail 
> with the subject: 'Concerns about ecash'.  

I was unclear in my original statement. You, Marcel, and others did
respond to my comments and questions-- specifically to my concerns
about when ecash systems would be available for real use. My upset
came from the fact that once my shop stopped working, I didn't get a
response.

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

> Sorry we *did* sent you a respons within an hour from your 
> request by my colleague Branko. He is responsible for our bank in 
> the trial. His respons was:

> -The dbm library used by Linux and FreeBSD are different, so the ecash
> -databases are also incompatible.  If you have a password for getting an
> -initial balance, you can also use this password for reopening your
> -account (and keeping your old balance).  For the server@fairgate.com
> -account you can use the password ********  (pw made invisible PD) for this.
> -
> -Branko

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

> We feel somewhat troubled by these comments.  We strongly feel that 
> the alleged 'lack of consideration' as unjustified.  First we would 
> like to split up your comment in to two different issues, first 
> regarding our potential customers and secondly the issue of Mr. S. 
> Brands.

First of all, Hal Finney wrote the paragraph which mentions lack of
consideration. My own feelings toward Digicash-- which you confirm--
are that you have more work to do than you can presently handle. I
understand that; it's not uncommon, and I don't hold it against you.
It _does_ hamper my ability to set up services for which I can be paid.

> We like you to consider this phase in the existence of ecash as a 
> genuin beta trail.  In beta test not only software is being trailed 
> but the supporting services too!  However, it should be noted that we 
> did respond to your mail and requests. 

This is a good point. I do understand that this is a beta test, and
that problems will occur. I also want to confirm for other readers
that you did respond to my mail; in the most important case I didn't
get the response.

> We will give a call today to check if received this mail. We hope to 
> resolve the problems mentioned above and to continue our co-operation.

Thanks for your detailed response.

Regards,
- -Paul Robichaux

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

iQCVAwUBLt9J/qfb4pLe9tolAQFABwP9FuFZvDeAzVlnFGqg5NwszbAoPN1IbV/2
SpD0bEdxbUkB+OdBCSkYgkcA0O/gU7MWFYNuJr062b8mwCBm5GLG8AGGq6dSYM+A
Tfdq/oi1F+yrkDcvq7t6TMfLcgiynylAfVqv1c8+SHrMxXtHDJ5hLlqvfJ43m09S
2nsZTGVd01s=
=rwxp
-----END PGP SIGNATURE-----