inamerrata

Each currency has to have a single dedicated bank to handle transactions. It requires a database containing an entry for every transaction that’s taken place. Each transaction needs to do a single element lookup from that database, and there shouldn’t be any locality of reference. Your storage requirements are O(T), and your transaction overhead is O(lg(T)) secondary storage operations. If each transaction takes 512 bytes of storage, then you can store about two million transactions per gigabyte.

As such, you have to retire a currency on a regular basis — otherwise you need arbitrarily large resources. How regular? If you have 1000 people, getting 1000 emails per day, that probably fills your two million transactions. A month’s email traffic for a small town would thus take up around 30GB. Covering a million people, say Brisbane, for a day hits a terabyte, or 10 100GB hard disks, ignoring redundancy. Coping with everyone in America, say 200 million people, would require 2000 100GB hard disks, per day. Doing that for a month, would take you up to six petabytes. Ouch. At $1/GB, each user costs 0.1c per 1000 transactions. That’s 35c/year per user for storage, which isn’t exactly going to break the bank. It does indicate costs would have to be very carefully managed, and that switching to actual charging (albeit small amounts) would be necessary fairly quickly.

It’s probably necessary to have the storage decentralised, rather than having to query a single, multi-petabyte datastore for every email anyone sends ever. Well, more certainly than probably. That necessitates multiple currencies, and an easy way to convert amongst them. Is it better to just have many floating currencies (which will happen due to competition anyway), or should we have multiple concurrent versions of a currency? ie, AJD.1, AJD.2, AJD.3, which a fixed 1:1 exchange rate? You only need to consult the transaction database to validate a coin, not to generate a new one, so that would make it easy for you to contact s1.ajcurrencyserver to exchange a coin denominated it AJD.1 and to get back a coin denominated in AJD.3. That allows you to do a reasonable degree of load balancing, doesn’t it? As long as the values are very small, it doesn’t let the bank mark the notes in a meaningful way (well, strictly it does, but you should be able to programmatically avoid any problems due to it easily enough). It does mean you have to be willing to accept AJD.* rather than a single currency, which could be awkward. I’m not sure if there are any cases where you care about the race condition where you can check one coin, have it pass, then check the second and have it fail. For email, you just take the coins and drop the mail. For markets, you refund the valid coins and start over.

Conclusions? Per transaction fees are required to pay for storage, as well as other running costs. Multiple currencies are necessary, probably even to the point of splitting a single notional currency at the implementation level, in spite of the complexities that introduces.