simplest possible ecash mint

Nomen Nescio nobody at dizum.com
Mon Dec 24 10:20:51 PST 2001


Ryan Lackey writes:
> * Some protocol for external communication (direct sockets is easiest,
>   but message-based protocols are far better, and allow a front end
>   processor to handle communications details)

A message is simply a packet of data.  Using a message-based protocol
says nothing about the underlying transport, sockets or carrier pigeons.
If you did this as a computational box with a communications front end
then a simple socket-based RPC protocol would probably be best between
the mint box and the comm box.

> * Reissue operation (powers of two coins; so you can pay with 1 x 2 coin
>   and get 2 x 1 coins back)

Sure.  You give a collection of coins worth $X, along with the blinding
factors appropriate to a different set of coins worth the same amount.
This fits well into the simple exchange mint concept.

> * A clock (decent rate RNG or PRNG is useful too, obviously)
> * A double spending database maintained internally

Right, and you better make sure it's not going to grow too big.  It
may be necessary to expire coins at fixed time intervals (every two
years or so).

> * Two account counters maintained internally: treasury and float
> * "Signed float": tell anyone who asks exactly how much has been
>    issued, signed as the mint.
> * A means of increasing or decreasing the treasury value, after
>   authentication, and ideally an internal log of these changes (which
>   could be published as well, signed)

Does this have per-user accounts in it?  If not, how does the float
amount ever change?  Do some people donate ecash to the bank's treasury
voluntarily, reducing the float?  No one would do that.  Are some people
entitled to receive ecash from the treasury?  Who and why?  Is this the
transfer-in mechanism, or simply a way for the banker to use the treasury
account as his personal slush fund?

What you really have are three kinds of transactions: those within the
system (pure ecash transfers), those out of the system (cashing in ecash
for dollars), and those into the system (purchasing ecash with dollars).
Maybe you could explain how you see these kinds of transactions working
in terms of your float and treasury account counters.

> * Key management functionality (signing keys generated onboard; some
>   kind of hierarchy so non-coins can be linked to coins)

What is this linkage for?

> * Ability to publish a description of some sort of the coins

Yes, and whatever public keys are appropriate for the protocol.

> * Power switch

Don't forget the light that tells you its on.  Really, this level of
detail is redundant.





More information about the cypherpunks-legacy mailing list