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@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