Magic Money status and future

[catalyst-remailer@netcom.com]

-----BEGIN PGP SIGNED MESSAGE-----

How is the budding digital cash economy going? How many coins are in
circulation, and how many transactions are taking place per day?
Are people just playing around, or are they exchanging things or services
of genuine value?

What's the address of the DigiFrank server, and where's it's key?

Recently I posted a functional spec for an automatic Magic Money client.
Nobody said anything about it. Does this mean that (a) it was good, or
(b) nobody cares? If you would have a use for this, please post and tell
me what you want it to do.

For a robust digital cash economy to develop, we will need multiple
servers. In fact, lots of them. We need a currency exchange, preferably
third-party (i.e. not a server operator) and for-profit. To use digital
cash safely, if servers are going to be run by arbitrary people, you
would have to hold many different currencies. This way if one server
goes bust (inflates its currency, gets its secret key stolen, ...) you
have not lost too much.

That means we need Magic Money 2.0. It needs to handle multiple currencies
transparently. You should be able to list your holdings of all currencies,
and the program should be able to track currency rates. A special message
format would allow a currency exchange to update the values stored in the
client automatically, just as the server can update the elist automatically.

I'm looking for design suggestions (and volunteers to code parts of it!)
One point I'm not sure on is: should you be able to pay out multiple
currencies in one payment? It could be done as long as a server-id field
was added to the coins.dat file. The problem is that when you go to
exchange those coins, the client would have to generate multiple messages,
each for a different server, and then you would have to mail each one to
the correct server. Is the complication worth it? How about a command-line
option to put the address of each server before its message? Then those
with direct net access could use a script to do all the mailing for them.

If PGP 2.6 comes out and becomes a de-facto standard, I will probably
update PGP Tools to support both formats. I might even write a patent-safe
PGP Tools which only does the 2.6 format and calls RSAREF (ugggh). But if
I do there will also be an MPILIB-based version which supports both.

                                           Pr0duct Cypher

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLeBnp8GoFIWXVYodAQGeYAQAoqquLcWcWRF8QNWP4mAY2qF0gYiBH3h7
WPAXIfp4niDtNwOvvLZ5iJQwjY88cuSm/LCqSWSSK4FPifm4M0wrUeWNnzXdzmLe
g4IMGNzrup8Xx38REiVxU8wDSht15/GYbBV4Co57EXBoSBqaCylezSCnHnGsn4nM
nGblnRjmPQ8=
=GfG2
-----END PGP SIGNATURE-----