simplest possible ecash mint

[Ryan Lackey]

Actually, I think to be practical you want something only
slightly more complex; 3x as much work, but 100x as useful.

Implemented in tamper-resistant hardware (a dedicated box or process
could substitute, but hardware is easier, and I have plenty):

stage 1:
* 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)
* Reissue operation (powers of two coins; so you can pay with 1 x 2 coin
  and get 2 x 1 coins back)
* A clock (decent rate RNG or PRNG is useful too, obviously)
* A double spending database maintained internally
* 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)
* Key management functionality (signing keys generated onboard; some
  kind of hierarchy so non-coins can be linked to coins)
* Ability to publish a description of some sort of the coins
* Power switch

This is great for a single currency on a single mint managed by a
single person.  There are several other refinements which can be added
over time which are meaningful:

* Seamlessly supporting multiple currencies on a single issuer, with
separate keys and managers

* Replication/distribution, for reliability and performance (obvious 
techniques)

* Means of programmatically linking treasury and float -- the box
opens its own remote account of some sort, or holds other electronic
instruments, and issues only up to that amount.

* Multi-user management interface to the mint, so a large company can
authorize a day manager to make small transactions, larger changes
requiring seniority or multiple users.

* Backup/recovery methods

* Scheduled key rollovers

* Misc. transports (handled by a front end processor and load
balancer; initially I'm using sockets, but I want to use email before 
releasing stage 1)


There really is NOT a huge amount of complexity.  I've done 3 separate
"stage 1" systems to about 80%, but using the chaum protocol.  To be
interesting, you would probably want agility on the underlying
cryptographic basis, including brands, wagner, chaum, client-side
blinding variants, unblinded when there are no variants, trivial
non-blinded non-crypto, and any other systems.

Writing a mint to stage 1 is maybe a month worth of work.  The
complexity is in developing a client library, library API, UI, and
integration into applications.

The easiest way I see to solve that is something I call a "hosted
wallet" -- a multiuser wallet, communicating with the user over SSL,
and using the ecash protocols to interact with the mint.  Any user
*could* run a hosted wallet server, but there is no client software
which MUST be installed.  Thus satisfying both security and ease of
use.  This is also vastly easier to develop than a client-side wallet,
at least for me -- html UI, much much easier than any of the unix or
windows widget sets, inherently crossplatform, etc.

I hope to have a mint and a wallet to demo at codecon in mid-feb in
sf, stage 1.  (which is why it was scheduled then, anyway)

I need about 60-120 more hours of actual productive work
to do so. (I'd like to have at least two ecash protocols implemented,
although at present I have "non-blinded dumb tokens" for testing, and
some non-integrated blinded code)

Ideally, I'd like it to be as easy to use as web-based mail; indeed,
integrating into a web-based mail UI might make sense for some demo
person to person payments.

This is really useful for absolutely nothing but testing.  All
practical applications require a much greater level of integration
with clients.  All interesting applications require multiple
currencies and a market.  Any level of interest at all from the public
will require an easy way to buy into the system using one or more
existing payment methods, which is something I've looked into with
high priority for the past 3 months, primarily from a gaming
background, but there's nothing to prevent people from playing with
the system itself before then.  Might as well start from day 1 with
real separation of roles, at least in name.

(one might note there are worthwhile conferences every 1-2 months from
now until september...)
-- 
Ryan Lackey [RL7618 RL5931-RIPE]	ryan at havenco.com
CTO and Co-founder, HavenCo Ltd.	+44 7970 633 277 
the free world just milliseconds away	http://www.havenco.com/
OpenPGP 4096: B8B8 3D95 F940 9760 C64B  DE90 07AD BE07 D2E0 301F