1994-12-14 - properties of FV

Header Data

From: eric@remailer.net (Eric Hughes)
To: www-buyinfo@allegra.att.com
Message Hash: 148620a2520849020446045756a4d02f7e284c00d7a7bd5b08076cf295593304
Message ID: <199412141644.IAA04167@largo.remailer.net>
Reply To: <UivSTnb0Eyt5NcCs4x@nsb.fv.com>
UTC Datetime: 1994-12-14 15:46:26 UTC
Raw Date: Wed, 14 Dec 94 07:46:26 PST

Raw message

From: eric@remailer.net (Eric Hughes)
Date: Wed, 14 Dec 94 07:46:26 PST
To: www-buyinfo@allegra.att.com
Subject: properties of FV
In-Reply-To: <UivSTnb0Eyt5NcCs4x@nsb.fv.com>
Message-ID: <199412141644.IAA04167@largo.remailer.net>
MIME-Version: 1.0
Content-Type: text/plain


   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





Thread