Anonymous writes:
> 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 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.
Very interesting proposal.
How communication and computationally intensive is the ZK proof as a
function of the coin list length? Could the proof be used in a
practical system?
(I am thinking that the coin list will grow indefinately as more coins
are used as the server nodes can't by design tell which coins are
spent).
> 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.
Couldn't one have a mintless method of injecting new coins into the
system by using hashcash in a similar way to that proposed by Wei Dei
in b-money [1]?
ie. the protocol you describe includes the step that upon submitting a
ZK proof of knowledge of blinding factor for one of the coins in the
coin list your can at the same time submit a replacement fresh coin.
A deposit step could be that upon submitting an n-bit hashcash token
(a n-bit partial hash collision on a chosen string) you can also
submit a new coin of the corresponding denomination. Appropriate
values for n could be chosen using the mechanisms Wei suggests in
b-money.
Other questions:
- is the ZK proof interactive? If so this would place communication
restrictions on spending -- payer and payee would need to be
simultaneously online.
- what about propagation delays in updating the spent coin list --
can't have people reusing the ZK proof at different servers
simultaneously to get more coins than they are due, or having the
payer deposit it simultaneously with the payee. This could make the
deposit step quite slow depending on network connectivity of
servers.
Adam
[1] Wei Dei's b-money protocol: http://www.eskimo.com/~weidei/bmoney.txt
