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

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

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

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

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

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

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