[freehaven-dev] hashcash double spending

[Michael J Freedman <mfreed@MIT.EDU>]

Hey Adam,

I've been working on FreeHaven's chapter in the O'Reilly peer-to-peer
book.  We're writing about the mechanisms which such systems use to
achieve accountability.

Right now, I'm starting to write about accountability via micropayment
schemes.  I'm discussing both non-redeemable micropayments (a la proof
of work: Dwork & Naor's postage, RSA Lab's client puzzles, your
hashcash, etc.) and cash-based micropayments (Chaum and Brands ecash,
MicroMint and PayWord, bread pudding schemes, etc.)

I wanted to ask you about double-spending protection for non-redeemable
micropayments.  Some of the schemes (such as client puzzles) use
interactive protocols to prevent replay and precomputations, and thus
effectively stopping the ability to double spend.  However, schemes such
as Dwork and Naor's postage and your hashcash, are non-interactive.

From your web page:
-------------------
Double spending protection

You can also ask the hashcash client to remember collisions within a
selected validity period.

The collision will only be added if all the tests pass (in validity
period, or required number of bits). The exit status also tells you if
the hash was ok.

The database would grow indefinitely as the mailer accepted new
payments, so the validity period is stored in the database, and at the
next use of the database after the validity period expires, the
collision will be discarded. There is no need to keep expired collisions
around because we wouldn't accept it anyway because it's out of date, so
who cares if we've previously accepted it. A validity period of 0 means
valid forever, and will never be discarded from the database.
--------------------

This works fine for Bob to stop Alice double spending the same coin
twice to him, but nothing to stop Alice from using the same hash coin to
pay Bob, Cathy, and Dave.

It would seem, though, without double spending checks between peers
(instead of only with self) this really doesn't help much to stop bulk
mailings:  generate a single coin whether you send the mail to 1 or n
recipients.  

Well, there's always the simple answer of online verification.  But,
it's not very decentralized, eh?  Wei Dai addresses a related problem in
his b-money protocol, but I need to think about it a bit more to better
understand its practicality and implications.

Am I missing something obvious, or any other thoughts?

Thanks,
--mike



-----
"Not all those who wander are lost."                  mfreed@mit.edu