1994-03-14 - Magic Money gripes

Header Data

From: Hal <hfinney@shell.portal.com>
To: cypherpunks@toad.com
Message Hash: 979b07c6b341719158c22392184342fd056278249c9e9d0b5e6843c9a20776c7
Message ID: <199403140620.WAA25305@jobe.shell.portal.com>
Reply To: N/A
UTC Datetime: 1994-03-14 06:20:02 UTC
Raw Date: Sun, 13 Mar 94 22:20:02 PST

Raw message

From: Hal <hfinney@shell.portal.com>
Date: Sun, 13 Mar 94 22:20:02 PST
To: cypherpunks@toad.com
Subject: Magic Money gripes
Message-ID: <199403140620.WAA25305@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


I hate to complain.  Magic Money is something that people have been asking
for for a long time, and it's a very nice implementation.  A lot of aspects
have been really well thought out, particularly the money aging and replace-
ment.  But I've been playing with it off and on lately and there are some
improvements needed IMO.

I'll just assume interested readers know how the program works and jump
right into it.

 - The program handles encryption of messages to and from the bank auto-
   matically, but makes the user have to handle encryption of messages to
   other people.  I can see some justification for this - maybe the message
   (that is, a coins.dat file) will be sent via secure means like a direct
   or IR connection, so encryption is not needed.  But most of the time it
   is needed, in which case the user has to use PGP or something as a sep-
   arate step.

 - The program distinguishes between bank messages, which are signed blinded
   coins, and user messages, which are raw coins, by whether they are in
   ASCII text or not.  This is not the significant distinction between these
   two kinds of messages.

 - Bank messages look just like other PGP messages.  But the user has to
   know not to try to run them through PGP and instead give them directly to
   the MM program un-decrypted.  The only way he can tell is to notice that
   the sender address is the bank.  If the bank ever sends him a real coin
   file (which it may to prime the pump) then the user just has to know
   to treat these messages differently.

 - There is no way to know which bank an incoming coin file is for.  I think
   this is one of the biggest weaknesses of the system.  If more than one
   bank is competing I have to know which bank a given coin file is
   associated with and go to that directory to process that coin file.

 - There is no way to put coin files directly into your allcoins.dat file.
   There are a couple of cases in which you might want to do this.  First,
   you might pay out some coins and then change your mind before sending
   them, and want to put them back.  Or second, you might receive some coins
   from a trustworthy person (your mum, say) and just want to add them
   without going through the bank.

 - More generally, it is difficult to use the program in a safe way which
   deals robustly with errors of various types.  When I was first building
   the program I had some bugs which caused coins to appear to be double-
   spent, to not signature-check properly, to not be found in the proto file,
   etc.  The program did not appear to handle all of these errors safely,
   sometimes aborting in the middle of a file.
   In addition, the program always calls its output files coins.dat and
   output.asc.  If you run it twice without renaming these files you can
   lose data and lose money.  Then, when you send the files, you need to
   manually keep backups in case the email fails.  Again, otherwise you will
   lose money.

 - The money data structures do not allow for expansion.  I'd like to see a
   way of adding new fields in the future which will be ignored by older
   versions of the program.  For example, in regard to the above, I'd like
   to see a "bank email address" and possibly a bank key added to the
   coins.dat file.  Then you could mail the coins to someone without including
   a lot of out-of-band data about the bank they were for.  It would be nice
   if this could be done without totally breaking the current program.  At
   a minimum a version number could be stuck at the front so that old programs
   would recommend that users upgrade.

 - The program uses PGP algorithms and data structures, but not its files.
   The bank's key and user's keys are kept in separate files.  There might
   be advantages in putting these keys into PGP's regular files.  Also, the
   random number generation in PGP looks stronger than MM, since it keeps
   much more state from run to run.  MM seeds based on a very, very elementary
   hash on a file called rand.dat, which will tend to be fixed, and the time
   of day.

 - None of the MM files are encrypted on the disk.  The money files could
   be stolen by someone with access to your computer, and your secret key
   used for communications with the bank could be stolen as well.  This
   would be a major security flaw in some situations.

Having made these complaints, let me reiterate that I am very pleased with
this program overall.  I also appreciate mpd@netcom.com's efforts in running
a server.  I have built a Mac client for MM which is not too mac-like but
lets you drag-n-drop incoming files onto the MM icon and it handles them
right.  I'll tweak that a little more then upload it with the other clients.

Hal





Thread