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.