Adam Back <[EMAIL PROTECTED]> writes:
> I wouldn't say ecash has to use blinding, but I would argue it would
> be a misuse of the word "ecash", if something which was revocable were
> dubbed ecash.
>
> With that definition it is not technically possible to implement
> electronic cash at all without tamper resistant hardware, because
> reliance on a mint, or double spend database means your "cash" can
> become worthless over night if someone (say a government) decides to
> switch off a computer (the one holding the double spending database).
> This is because the value isn't held by the bearer, it is secret split
> between the mint (in it's double spend database) and the bearer (in
> his token), rather than being held solely by the bearer as the token.
Consider the following system, not yet completely practical, but perhaps
with some more work it could be made so. Features:
- A "mint" is used only to create the initial allocation of ecash.
After that it is not needed.
- Complete anonymity as with Chaum ecash.
- No single point of failure, distributed public databases are used.
- No secret keys to be lost or stolen.
The idea is based on a simpler version of Sander and Ta-Shma's proposal at
Crypto 99. In this system, in addition to a spent coin list, there is an
issued coin list. The latter holds f(r,x) where x is the coin's serial
number, r is a random blinding factor, and f() is a one way function,
for all coins which have been issued.
When the mint creates a new coin, the user secretly chooses r and x, and
send f(r,x) to the bank, which puts that value on the issued coin list.
To spend/deposit the coin, the user reveals x and supplies a zero
knowledge proof that he knows an r such that f(r,x) is on the issued
coin list (he doesn't reveal r or f(r,x) though). The recipient also
checks that x is not on the spent coin list. These tests assure that
the coin is valid.
Furthermore, the deposit is unlinkable to the withdrawal as no information
is revealed which is common to the two. During withdrawal only f(r,x)
is revealed, and during deposit only x is revealed. This makes the
system completely anonymous, giving the effect of blind signatures
without blinding or signatures!
The issued coin list is maintained as a hash tree and so the zero
knowledge proofs of membership are (possibly, barely) feasible. The need
for potentially cumbersome ZK proofs is one of the weak points of this
proposal.
As stated this is still a mint based system. Here is a new enhancement
that gets the mint out of the picture.
The issued and spent coin lists would not be maintained by the mint, but
rather would be public databases. A network of multiple redundant
servers maintains these lists.
When a merchant receives a coin, he broadcasts the ZK proof of its
validity, plus the serial number x. The latter gets added to the spent
coin list. This broadcast entitles him to create a new coin. He does
so by picking new r,x and adding f(r,x) to the issued coin list, as part
of the same broadcast which updates the spent coin list.
The server network monitors these broadcasts and updates the issued and
spent coin lists appropriately. Anyone who receives a coin is therefore
able to immediately create a new one, by getting it added to the issued
coin list.
This feature, of being able to receive money and immediately create
new, unrelated coins, is the enhancement that allows us to do away with
the mint. The mint is only needed to inject new coins into the system;
otherwise the money supply stays constant.
In practice operating the distributed coin lists may have difficulties, in
the face of possible legal attacks. Ideally clients can cross-check their
database accesses against multiple servers to detect if one or more have
bogus data. In addition well-connected clients can in principle maintain
their own copy of the databases by dipping into the transaction stream.
More work is needed, but this approach provides the basis for a free,
public, anonymous cash system with no single point of failure. It could
be a useful alternative to traditional mint based models.
