12.10.1. "If digital money is so great, why isn't it being used?"
- Hasn't been finished. Protocols are still being researched,
papers are still being published. In any single area, such
as toll road payments, it may be possible to deploy an
application-specific system, but there is no "general"
solution (yet). There is no "digital coin" or unforgeable
object representing value, so the digital money area is
more similar to the similarly nonsimple markets in
financial instruments, commercial papers, bonds, warrants,
checks, etc. (Areas that are not inherently simple and that
have required lots of computerization and communications to
make manageable.)
- Flakiness of Nets. Systems crash, mail gets delayed
inexplicably, subscriptions to lists get lunched, and all
sorts of other breakages occur. Most interaction on the
Nets involves a fair amount of human adaptation to changing
conditions, screwups, workarounds, etc. These are not
conditions that inspire confidence in automated money
systems!
- Hard to Use. Few people will use systems that require
generating code, clients, etc. Semantic gap (generating
stuff on a Unix workstation is not at all like taking one's
checkbook out). Protocols in crypto are generally hard to
use and confusing.
- Lack of compelling need. Although people have tried various
experiments with digital money tokens or coupons (Magic
Money/Tacky Tokens, the HeX market, etc.), there is little
real world incentive to experiment with them. And most of
the denominated tokens are for truly trivial amounts of
money, not for anything worth spending time learning. No
marketplace for buyers to "wander around in." (You don't
buy what you don't see.)
- Legal issues. The IRS does not look favorably on
alternative currencies, especially if used in attempts to
bypass ordinary tax collection schemes. This and related
legal issues (redemptions into dollars) put a roadblock in
front of serious plans to use digital money.
- Research Issues. Not all problems resolved. Still being
developed, papers being published. Chaum's system does not
seem to be fully ready for deployment, certainly not
outside of well-defined vertical markets.
12.10.2. "Why isn't digital money in use?"
- The Meta Issue: *what* digital money? Various attempts at
digital cash or digital money exist, but most are flawed,
experimental, crufty, etc. Chaum's DigiCash was announced
(Web page, etc.), but is apparently not even remotely
usable.
+ Practical Reasons:
- nothing to buy
- no standard systems that are straightforward to use
- advantages of anonymity and untraceability are seldom
exploited
- The Magic Money/Tacky Tokens experiment on the Cypherpunks
list is instrucive. Lots of detailed work, lots of posts--
and yet not used for anything (granted, there's not much
being bought and sold on the List, so...).
- Scenario for Use in the Near Future: A vertical
application, such as a bridge toll system that offers
anonymity. In a vertical app, the issues of compatibility,
interfaces, and training can be managed.
12.10.3. "why isn't digital cash being used?"
+ many reasons, too many reasons!
+ hard issues, murky issues
- technical developments not final, Chaum, Brands, etc.
+ selling the users
- who don't have computers, PDAs, the means to do the
local computations
- who want portable versions of the same
+ The infrastructure for digital money (Chaum anonymous-
style, and variants, such as Brands) does not now exist,
and may not exist for several more years. (Of course, I
thought it would take "several more years" back in 1988,
so what do I know?)
- The issues are familiar: lack of standards, lack of
protocols, lack of customer experience, and likely
regulatory hurdles. A daunting prospect.
- Any "launches" will either have to be well-funded, well-
planned, or done sub rosa, in some quasi-legal or even
illegal market (such as gambling).
- "The american people keep claiming in polls that they want
better privacy protection, but the fact is that most aren't
willing to do anything about it: it's just a preference,
not a solid imperative. Until something Really Bad happens
to many people as a result of privacy loss, I really don't
think much will be done that requires real work and
inconvenience from people, like moving to something other
than credit cards for long-distance transactions... and
that's a tragedy."[L. Todd Masco , 1994-08-20]
12.10.4. "Is strong crypto needed for digital cash?"
- Yes, for the most bulletproof form, the form of greatest
interest to us and especially for agents, autonomous
systems
+ No, for certain weak versions (non-cryptographic methods of
security, access control, biometric security, etc. methods)
- for example, Internet billing is not usually done with
crypto
- and numbered Swiss accounts can be seen as a weak form of
digital cash (with some missing features)
- "warehouse receipts," as in gold or currency shipments
12.10.5. on why we may not have it for a while, from a non-Cypherpunk
commenter:
- "Government requires information on money flows, taxable
items, and large financial transactions.....As a result, it
would be nearly impossible to set up a modern anonymous
digital cash system, despite the fact that we have the
technology.....I think we have more of a right to privacy
with digicash transactions, and I also think there is a
market for anonymous digicash systems. " [Thomas Grant
Edwards. talk.politics.crypto, 1994-09-06]
12.10.6. "Why do a lot of schemes for things like digital money have
problems on the Net?
+ Many reasons
- lack of commercial infrastructure in general on the
Net...people are not used to buying things, advertising
is discouraged (or worse), and almost everything is
"free."
- lack of robustness and completeness in the various
protocols: they are "not ready for prime time" in most
cases (PGP is solid, and some good shells exist for PGP,
but the many other crypto protocols are mostly not
implemented at all, at least not widely).
+ The Net runs "open-loop," as a store-and-forward delivery
system
- The Net is mostly a store-and-forward netword, at least
at the granularity seen by the user in sending
messages, and hence is "open loop." Messages may or may
not be received in a timely way, and there is little
opportunity for negotiaton on a real-time basis.
- This open-loop nature usually works...messages get
through most of the time. And the "message in a bottle"
nature fits in with anonymous remailers (with
latency/delay), with message pools, and with other
schemes to make traffic analysis harder. A "closed-
loop," responsive system is likelier to be traffic-
analyzed by correlation of packets, etc.
- but the sender does not know if it gets through (return
receipts not commonly implemented...might be a nice
feature to incorporate; agent-based systems
(Telescript?) will certainly do this)
- this open-loop nature makes protocols, negotiation,
digital cash very tough to use--too much human
intervention needed
- Note: These comments apply mainly to _mail_ systems,
which is where most of us have experimented with these
ideas. Non-mail systems, such as Mosaic or telnet or
the like, have better or faster feedback mechanisms and
may be preferable for implementation of Cypherpunks
goals. It may be that the natural focus on mailing
lists, e-mail, etc., has distracted us. Perhaps a focus
on MUDs, or even on ftp, would have been more
fruitful...but we're a mailing list, and most people
are much more familiar with e-mail than with archie or
gopher or WAIS, etc.
- The legal and regulatory obstacles to a real system, used
for real transactions, are formidable. (The obstacles to
a "play" system are not so severe, but then play systems
tend not to get much developer attention.)
12.10.7. Scenario for deployment of digital cash
- Eric Hughes has spent time looking into this. Too many
issues to go into here, but he had this interesting
scenario, repeated almost in toto here:
- "It's very unlikely that a USA bank will be the one to
deploy anonymous digital dollars first. It's much more
likely that the first dollar digital cash will be issued
overseas, possibly London. By the same token, the non-
dollar regulation on banks in this country is not the same
as the dollar regulation, so it's quite possible that the
New York banks may be the first issuers of digital cash, in
pounds sterling, say.
"There will be two stages in actually deploying digital
cash. By digital cash, here, I mean a retail phenomenon,
available anybody. The first will be to digitize money, and
the second will be to anonymize it. Efforts are already
well underway to make more-or-less secure digital funds
transfers with reasonably low transaction fees (not
transaction costs, which are much more than just fees).
These efforts, as long as they retain some traceability,
will almost certainly succeed first in the marketplace,
because (and this is vital) the regulatory environment
against anonymity is not compromised.
"Once, however, money has been digitized, one of the
services available for purchase can be the anonymous
transfer of funds. I expect that the first digitization of
money won't be fully fungible. For example, if you allow
me to take money out of your checking account by automatic
debit, there is risk that the money won't be there when I
ask for it. Therefore that kind of money won't be
completely fungible, because money authorized from one
person won't be completely identical with money from
another. It may be a risk issue, it may be a timeliness
issue, it may be a fee issue; I don't know, but it's
unlikely to be perfect.
"Now, as the characteristic size of a business decreases,
the relative costs of dealing with whatever imperfection
there is will be greater. To wit, the small player will
still have some problem getting paid, although certainly
less than now. Digital cash solves many of these problems.
The clearing is immediate and final (no transaction
reversals). The number of entities to deal with is greatly
reduced, hopefully to one. The need and risk and cost of
accounts receivables is eliminated. It's anonymous. There
will be services which will desire these advantages, enough
to support a digital cash infrastructure. [Eric Hughes,
Cypherpunks list, 1994-08-03]
By Tim May, see README
HTML by Jonathan Rochkind