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.
| 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?
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.
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
-----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
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...
-----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-----
participants (8)
-
cactus@seabsd.hks.net -
db@Tadpole.COM -
eric@remailer.net -
jamesd@netcom.com -
Nathaniel Borenstein -
Paul Dinnissen -
paul@poboy.b17c.ingr.com -
Richard Johnson