cyphrpunk wrote:
If this is the model, my concern is that in practice it will often be
the case that there will be few intermediate exchanges. Particularly
in the early stages of the system, there won't be that much to buy.
Someone may accept epoints for payment but the first thing he will do
is convert them to "real money". A typical transaction will start with
someone buying epoints from the issuer using some identified payment
system, spending them online, and then the recipient redeems them
using an identified payment system. The issuer sees exactly who spent,
how much they spent and where they spent it. The result is that in
practice the system has no anonymity whatsoever. It is just another
way of transferring value online.

That's a "merchant" business model.  Typically, that's
not how payment systems emerge.  Mostly, they emerge
by a p2p model, and then migrate to a merchant model
over time.  How they start is generally a varied question,
and somewhat a part of the inspiration of the Issuer.

According to the Issuer's design, he may try and force
that migration faster or slower.  In a more forced
system, there is typically only one or a few exchange
points and that is probably the Issuer himself.  If
the Issuer also pushes a merchant design, and a
triangular flow evolves, the tracing of transactions
is relatively easy regardless of the system because
time and amount give it away.  But, typically, if the
Issuer has designs on merchant business, he generally
doesn't care about the hyphed non-tracking capabilities
of the software, and also prefer the tracking to be
easy for support and segmentation purposes.

A game that Issuers often play is to pretend or market
a system as privacy protecting, but if their intention
is the merchant model then that game stops when the
numbers get serious.  (I gather they discuss that in
the Paypal book if you want a written example.)

Either way, it is kind of tough to criticise a software
system for that.  It's the Issuer and the market that
sets the tune there;  not the software system.  The
ideal software system allows the Issuer to decide
these paramaters, but it is also kind of tough to
provide all such paramaters in a big dial, and keep
the system small and tight.  (I suppose on this note,
this is a big difference between Daniel's system and
mine.  His is small and tight and he talks about being
able to audit the 5 page long central server ... mine
is relatively large and complex, but it can do bearer
and it can do fully traceable, as well as be passably
extended to imitate of his design.)  Meanwhile, the
Issuers who want to provide privacy with a bog
standard double entry online accounts system still
have a better record of doing that than any other
Issuers that might have boasted mathematical blah
blah, they just run theirs privately.  e.g., your
average Swiss bank.


Reply via email to