Re: Simplest possible ecash mint
On 24 Dec 2001, at 9:40, Nomen Nescio wrote: How simple can an ecash mint be? For the simplest case there should be no accounts. All the mint does is exchange coins for other coins. There are no customer lists, no records of transactions (except as needed for double-spending detection). In order to give value to ecoins, it is necessarily to make them convertible with some other currency, normally an account based currency. It is difficult to do this without supporting accounts. One could of course have a pile of gold, and physically and in person exchange coins for physical gold, but it is considerably more convenient to exchange coins for account based money, such as e-gold. It is difficult to make such transactions entirely atomic, because of the possibility that something might go wrong, requiring durable state. We then need a database key for that state. Such a database key looks rather like an account By itself, this trivial mint can support a transaction system, and in principle a whole economy. For Alice to pay Bob, she gives him coins. Bob exchanges them at the mint for new coins, thereby checking that they are good. End of transaction. Bob can spend his new coins elsewhere, unlinkable to the exchange. This only works if the transaction is complete and final, for example downloading pornography, or for people who meet physically, and exchange physical assets for ecash. If the transaction is for account assets outside the system, then the transaction must have state that looks very like an account, if only a transient account. The mint does not even have to be involved in transfers between ecash and other forms of payment. This is one of the things the e-gold people got right. They outsourced in- and out-transactions. You go to any of dozens of coin dealers, currency services, shady operators of all stripes, to get money into or out of your e-gold account. The same thing would work here. Third parties would offer to buy or sell ecash for dollars, grams of gold, hi grade cocaine, etc. The value of e-gold is ultimately maintained by physical transfers with a pile of gold inside a vault outside US jurisdiction. It takes a great deal of time and cost to actually transfer stuff to and from that vault, hence the numerous intermediaries. The intermediaries therefore find it convenient to maintain accounts with e-gold. While accounts are not needed for many transactions, and should be avoided where possible, they are convenient for many transactions, and essential for some.
Simplest possible ecash mint
How simple can an ecash mint be? For the simplest case there should be no accounts. All the mint does is exchange coins for other coins. There are no customer lists, no records of transactions (except as needed for double-spending detection). The very simplest mint is a pure ecoin changer. You give it a coin and it gives you a new one in return. It checks that the coin you gave it is valid and has not been spent before. You also supplied blinding factors so that the new coin you get is blinded and will not be recognized by the mint when spent later. By itself, this trivial mint can support a transaction system, and in principle a whole economy. For Alice to pay Bob, she gives him coins. Bob exchanges them at the mint for new coins, thereby checking that they are good. End of transaction. Bob can spend his new coins elsewhere, unlinkable to the exchange. The mint does not even have to be involved in transfers between ecash and other forms of payment. This is one of the things the e-gold people got right. They outsourced in- and out-transactions. You go to any of dozens of coin dealers, currency services, shady operators of all stripes, to get money into or out of your e-gold account. The same thing would work here. Third parties would offer to buy or sell ecash for dollars, grams of gold, hi grade cocaine, etc. As described, this mint has a constant money supply. There is neither creation nor destruction of coins. In practice there would be slow destruction due to occasional losses of data. This could lead to very slow deflation, or the mint could be adjusted to slightly inflate the currency in order to compensate for this effect.
simplest possible ecash mint
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][EMAIL PROTECTED] 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
Re: Simplest possible ecash mint
Tim writes: This is a terribly important point. Implementing this atomic transaction would be a major step. Having a Web site that does this EVEN WITH PLAY TOKENS would be a useful step. There used to be a little toy server run by Software Agents at www.netbank.com. It exchanged something called NetCash which had the following format. NetCash US$ 10.00 A123456B789012C You could mail the server encrypting with its public key, and it would send you back the results encrypted with any password you specified. The server could do a number of simple things, like exchange tokens for new ones, make change, combine a bunch of tokens into a single one, and check tokens for validity. You could deposit tokens and they would mail you a check, or you could mail them a check, and they would issue tokens. It was a cute little system, restricted to amounts under $100, and got some use by BBS systems which accepted the tokens to pay for a subscription. Anyone remember this? It apparently folded, and netbank.com is now a real bank. -- Eric Michael Cordian 0+ O:.T:.O:. Mathematical Munitions Division Do What Thou Wilt Shall Be The Whole Of The Law
Re: simplest possible ecash mint
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.
Re: simplest possible ecash mint
I don't believe normal users should ever interact directly with the mint; using the mint as a reissue server only in normal operation is a key optimization -- especially when coupled with tamper-resistant mint hardware. Easier to develop, easier to operate, easier to audit. Users should purchase cash from change makers; the issuer could also operate a change maker, and can handle sales to change-makers separately. The mint should be able to report to the world exactly how many coins it has issued -- for without this figure, it would be difficult for users to trust that an issuer has not inflated the currency (I think free banking theory would disagree with this, proposing instead that competitors attempt to test withdrawals regularly, but I still think publishing a float figure is important). This also demands that certain keys be generated on the mint and only under the mint's control, not under even the issuer's control, except through logged and proscribed actions. I simply want there to be a way for the issuer of a currency to increase the authorized amount and withdraw the tokens, in a way which is logged by the mint itself. Otherwise, you need an external means of generating the initial batch of signed currency, the problem with currency withering away over time, etc. Much better to make it a clean part of the design. The issuer of the currency would be able to increase or decrease the authorized amount of cash (treasury), and could request from the mint an amount of tokens up to that amount. The issuer could also send coins and have them destroyed, and they would be subtracted from float. The reason for doing this explicitly is that in the future one may replace issuer manually sets the treasury with mint directly contacts an external server to see account balance, publishing that as treasury, with rules internal to the mint on how much of various assets must be held to issue a currency -- perhaps you could have a derivative instrument issued against another token-based currency, where the mint itself held a single large coin in another issue. If you made it a single step (increase treasury directly results in increase in float, by sending coins to the treasury) it would make automatic/external changes to the treasury more difficult, due to the need for a multi-stage blinding protocol. A multi-currency mint would just have multiple accounts of this form, two for each currency, plus associated keys. This makes it very easy to separate mint-operator from currency issuer, etc. [linkage of signing keys and external keys] I'd like there to be a way for a textual description of the issue, the issuer signing keys, and external means of reputation/identity to be verified; this is just a question of what keys sign what and how to present it. -- Ryan Lackey [RL7618 RL5931-RIPE][EMAIL PROTECTED] 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
Re: simplest possible ecash mint
Ryan Lackey writes: I don't believe normal users should ever interact directly with the mint; using the mint as a reissue server only in normal operation is a key optimization -- especially when coupled with tamper-resistant mint hardware. Easier to develop, easier to operate, easier to audit. Users should purchase cash from change makers; the issuer could also operate a change maker, and can handle sales to change-makers separately. You're using some of these terms without defining them clearly: mint, issuer, and change maker. Earlier you said the change maker was responsible for changing between ecash and something of value, presumably including other currencies. Presumably the mint is the cryptographic engine which issues ecash coins. The issuer is apparently someone who is allowed to force the mint to issue coins at will, although the mint is supposed to log and report on such interventions. (Anyone can destroy coins, so an issuer is not needed for that functionality.) Can you explain how these three roles would work in a transaction where Alice gets some ecash for dollars, pays Bob in ecash, who turns the ecash back into dollars? Here is how it seems like it should work. The change maker Carol has a bunch of ecash she stands ready to sell. Alice gives her $X in dollars, along with blinded data to become Alice's ecash. The change maker does an exchange operation at the mint, giving the mint $X in the change maker's own coins, along with the blinding factors from Alice. The mint gives back new blinded coins which Carol passes to Alice, who unblinds them to get her ecash. Alice passes the ecash to Bob. He does an exchange operation at the mint to get new coins and to verify that Alice's cash is good. He then delivers whatever goods or service Alice has paid for. Bob later wants dollars, so he goes to change maker Carol and delivers to her ecash. She does an exchange at the mint to verify that Bob's coins are good, and then sends Bob dollars in return for his ecoins. This sequence conflicts somewhat with your model. Bob had to interact directly with the mint, and you said that normal users would not. But only the mint can verify the validity of coins so it seems to be necessary. The issuer was not involved in this transaction. Apparently he is only there to inflate the currency. You should consider eliminating the issuer, who can easily cause trouble. At startup time let the mint generate its keys and emit a single high-value coin. That will be the money supply for all time. Allow a banking system to grow around this high-powered currency and fractional reserve bank loans will automatically adjust the money supply as needed. See Selgin, http://www.terry.uga.edu/~selgin/.
