Which E-Currency Issuer?

“P” is for privacy, “P” is for...—he who shall not be named—why free swaps used to be better than warranted searches—why the last shall be first—going the way of all flesh—the results of the privacy stakes—what to do in practice, be you a buyer or a merchant. ... Masochistium Clickium Hic!

“P” is for Privacy, “P” is for ...

Now there are different reasons why you might choose an e-currency issuer and we’ll compare the candidates on a point by point basis when we get around to it. But we thought it would be nice to offer some thoughts on the matter dearest to our hearts: which e-currency issuer should you choose on the grounds of privacy. While all e-currencies offer the convenience and certainty of non-reputiable transactions, e-currencies provide varying degrees of anonymity. The ideal is an e-currency issuer who

  • Operates on a “don’t-know-your-client” basis
  • Keeps no records of client transactions

If these two conditions are met then even if Big Brother commandeers the issuer’s data processing centre he will be no wiser when he leaves than when he entered.

The anonymous e-currency niche is a small one, but a relatively easy one to enter. Because of the increased interest by governments in the mass surveillance of financial transactions the world’s main financial players, who operate both onshore and offshore, cannot easily play in the anonymous e-currency market. They are forbidden from doing so onshore—except perhaps for small value transactions—by laws that require them to operate on a “know-your-client” basis. Were they to do so offshore then governments would take action, whether within or outwith the law, to ensure that the issuers were disadvantaged commercially as far as their onshore operations were concerned. And while e-currencies have been growing very rapidly, they have started from a very low base, and are only beginning to command the interest of the major players by way of small but interesting acquisitions.

These restrictions leave the anonymous e-currency niche open to any small enterprise that can consistently demonstrate itself to be trustworthy and reliable. Demonstrating reliability of operation is relatively easy, but as with any quasi-offshore business the appellation “trustworthy” only comes after many years of clients finding that they can “take out” that which they have “put in”!

While primary e-currency issuers require a moderate amount of capital to set up the infrastructure needed to safely store and routinely audit the precious metals that provide 100% backing for the e-currencies that they issue, secondary e-currency issuers that resell primary e-currencies under their own name have negligible set-up costs.

The main problem for the e-currency issuers is that while they readily attract a small and loyal following, making their e-currencies attractive to merchants is an uphill struggle. Without major financial backing and a high rate of cash-burn that effectively buys market share by giving away free cash, growth is, as the euphemism has it, organic!

At present there are three candidates that offer varying degrees of privacy, and who have been around for long enough for us to be reasonably certain that they will not run away with our gold. So if you’re interested in privacy which one of the big three should you select: Pecunix, e-gold, or 1mdc? (And that, dear reader, is called a hint!)

He who shall not be named

It’s a digression, but you may wonder why we always refer to the big three and not, as other commentators on e-currencies do, to the big four. Well, if you’ve seen that Harry Potter film you may recall the discussion between Harry and Hagrid in Diagon Alley, when Harry is told that the evil Lord Voldemort is always referred to by way of the phrase “He who shall not be named”. Well, like Lord Voldemort the invisible fourth member of the big four is as far as freedom loving people are concerned a name that we do not mention in polite society (well, if you must know it’s called “GoldMoney”).

GoldMoney operates under the same “know-your-client” rules that we might expect from the average bank. It requires detailed information about its account holders—notarized no less—though you can open an account and perform some limited transactions without verification. The following extract from their T&Cs gives you a flavour:

Unctuousness Personified

GoldMoney has a Customer Acceptance Policy (CAP) so that it can comply with established know-your-customer regulations for financial institutions ... all financial institutions are required to verify the name and address of their customers and the source of the customer funds entrusted to them.

While in some respects GoldMoney may seem similar to e-gold, there is a distinct difference in ethos. GoldMoney is, we feel, an unctuous servant of Big Brother, through and through. E-gold’s at times servile behaviour is dictated more by the practicalities of its location and by its aspiration to be a major financial player onshore. The other reason to shun GoldMoney is that it has gained a reputation for operating its accounts on a hair-trigger, and—taking a leaf from the Paypal rule book—of freezing accounts at a whim. Security demands that you are able to get access to your gold immediately: the price of gold can rise and fall rapidly in response to world events; were you to buy near a peak you would not wish to wait for months watching the gold price rapidly fall before your account was unfrozen.

So now you know why we speak of the big three and not of the big four!

E-gold versus 1mdc

This used to be an easy one to call. 1mdc tells us it operates entirely off-shore. E-gold’s data processing centre is in the US. As far as we know 1mdc does not disclose account details to third parties. E-gold tells us on its web site that “Our staff has participated in hundreds of investigations supporting the FBI, FTC, IRS, DEA, SEC, USPS, and others.”

Now we’re all for putting an end to crime, but what is a whistleblower to do when the government that instigates investigations contains within it the very criminal elements that the whistleblower is intent on exposing? And while we have every sympathy with the Agent Starlings of this world this sympathy does not extend to their political masters who find it difficult to distinguish between public interest and private gain, who seek to use the information gleaned from mass surveillance campaigns to manipulate public opinion, and who further their own political ends by passing on personal information garnered under the pretext of fighting crime to their paymasters within Big Business. The founders of the good old “US-of-A” were wise enough to place some restraints on the executive, but sadly that executive has found ways to get around them.

At the end of the day it comes down to which you fear the most, the criminals within, or the criminals outwith, governments. It we look around the world today we can ask who causes the most misery, those individuals acting at the behest of governments or those individuals acting at the behest of organized crime? The question is rhetorical, for the depredations of governments vastly outnumber those of organized crime. The peoples of the world have unwittingly allowed governments to gather unto themselves ever greater powers, powers that they abuse with deliberate intent, or, in the most charitable of interpretations, lack the wisdom to use wisely. So, we, the people, must wrest back from governments these powers, and where we face the uncomfortable choice between two evils, we must tackle first that which is the greater of the two.

Now you’d think the US government would appreciate e-gold’s cooperation in these matters. But no. On e-gold’s web site we read:

Biting the hand that feeds you

Starting in mid-December 2005, Gold & Silver Reserve, Inc. (G&SR), contractual Operator and primary dealer for e-gold, has been the subject of a warranted search of its premises and records, had its domestic bank accounts frozen, and been the target of a precisely timed, extraordinarily misleading attack by a major business publication. ... The examination utilized the full resources of e-gold's system and prevented customer access. We were told by the government examiners that the outage would be for a few hours, however, due to the volume of data maintained by e-gold for its customers' protection, a surprise to the examiners, the examination occupied e-gold's computing capacity for 36 hours.

“Maintained by e-gold for its customers’ protection”—ironic isn’t it? And 36 hours—the mind boggles! Had the government examiners just wanted details of the transactions made by a few hundred suspects then there would have been no need to bring e-gold’s operations to a grinding halt. It seems like a blatant attempt by the US government to damage a business whose operations are perfectly lawful but which the US government doesn’t approve of—a standard Big Brother ploy.

While we salute e-gold’s founder for his vision of a gold-based economy, he clearly did not appreciate that the playing field would not be level, that he would have to fight with one hand tied behind his back, and that the “so called” referee would trip him up at every opportunity. Sadly, e-gold seems to be at a fork in the road: either it becomes a pseudo-bank or, if it wishes to keep the vision alive, it must move off-shore.

The US has long ceased to be a democracy in which the executive makes policy that is implemented in a transparent and even-handed fashion by impartial public servants. Instead it has become a tyranny where the executive directs the operations of those public servants to its own ends. Francis Scott Key must be looking down with sadness from his place amongst the heavenly hosts, for while the US may still be “the home of the brave”, it has long since ceased to be “the land of the free”.

What’s important here is what e-gold doesn’t say. E-gold doesn’t say that the US government now has a copy of every transaction made by every e-gold account holder, including the relevant IP addresses, going back to the year dot (1996 in the case of e-gold). E-gold doesn’t say that the US government has shared this information with other “friendly” countries (and the US government keeps some strange company—Saudi Arabia, for example; and even in the case of hostile states information is often bartered). E-gold doesn’t say that the details of all these transactions are now being correlated by disparate governments with information obtained from other sources. And we’re not saying that any of these statements is true either. We just don’t know. But we can speculate! What would a government keen to tap everybody’s phone do with a database full of everybody’s transactions? Well Sherlock, even Watson could make a valid deduction in this case! What’s important here is not what e-gold says, but what every man and his dog thinks!

So it would be prudent to assume that the US government and it’s hangers-on around the world have a direct line into e-gold’s transaction database. That doesn’t rule out e-gold entirely from a privacy point of view. E-gold still does not validate your personal details, for which it is to be commended (though a GoldMoney-like scenario looms ever larger on the horizon). If you access your account using a good proxy chain, such as Tor, then you still have a measure of protection. But beware: analysis of transaction details can make it easy to identify you. The transaction database will allow any interested party to determine what merchants you’ve done business with. So if you’ve given personal information to anyone on the other side of an e-gold transaction—if you’ve ever purchased any physical goods using e-gold for example—then provided the US government or its “friends” can get access to that party’s records—and they often have “ways and means”—then your anonymity is blown. So if you’re a whistleblower or a dissident—no matter where you live in the world—and you are using e-currency to pay for a web site, for example, then stay clear of e-gold—if it’s worth their while, then governments and their friends may not find it too difficult to track you down.

So clearly, you should choose 1mdc ahead of e-gold. Well, it used to be that way, but not any more as we’ll see below!

Pecunix: And the last shall be first!

Now Pecunix has a more stylish interface than its competitors; Pecunix has more features than its competitors; and Pecunix offers greater security than its competitors. Yes, all very well, but what about privacy, the focus of this blog entry?

Well when it comes to privacy Pecunix not only belongs in a different category to e-gold and 1mdc, it belongs on a different planet! Or, if you’ll forgive us changing and elevating the metaphor still further: it’s a star shining brightly in the firmament of the great god Zimmerman, because, Pecunix, unlike its competitors, is PGP savvy (indeed if you want to quickly assess the privacy credentials of any site just ask the question, “Does it use PGP, and, if so, for what purposes?”). Now while the use of PGP with Pecunix is entirely optional, if you add a public key to your account then you will get much in return for your efforts.

When you get an email containing a PIN from almost any financial site on the Internet the email is sent as plain text, which means that every man and his dog could know what your PIN is long before you do! Your email has passed through multiple Internet routers and finally to your ISP’s mail server. You can be pretty sure that at least one Big Brother has sniffed the contents somewhere along the line, to say nothing of organized crime. But with PGP enabled, the PIN you receive from Pecunix comes in an encrypted email. And not only is the PIN encrypted, so too are all emails that you receive from Pecunix. And this kindness can be reciprocated since Pecunix’s PGP key is readily downloaded from its site for the purposes of (1) verifying that the email you’ve received is actually from Pecunix, and is not the result of some phishing expedition; and (2) encrypting your reply to Pecunix should one be warranted.

The next felicity that comes with PGP is a rock-solid mechanism for account verification. With PGP enabled if you don’t enter any personal information when creating a Pecunix account, you can still regain access to your account using PGP should you lose your password. No need to use your mother’s maiden name or avail yourself of other equally risible, cretinous, and hacker-friendly methods of password retrieval, methods that seem to be employed by almost all web sites. Hence, it can be said unequivocally that Pecunix operates on a “don’t-know-your-client” basis.

There is a fundamental privacy principle that any exemplary web site will hold fast to: authorization without identification. When it comes to logging into such a site you are your PGP key. And if you need multiple personae for different purposes, then you use a different PGP key for each persona. With Pecunix you have the option of using PGP for authorization providing unexcelled logon security, which is one of the reasons why Pecunix is also the issuer of choice for large-scale asset holding (but we’ll discuss security another day).

Wonderful isn’t it? Pecunix has always been by far the most impressive of the big three when it comes to privacy—impressive that is until you tried to create a Pecunix account and discovered that you couldn’t! And the reason you couldn’t was because you had disabled Javascript in your browser, and Pecunix wouldn’t allow you to create an account with Javascript disabled. Given the dangers of digital fingerprinting with the subsequent loss of anonymity that the use of Javascript entails, no one with an interest in privacy is going to take the risk. Hence, it was with a heavy heart that we said some time ago, “They stand head and shoulders above the competition in every other respect, but this one defect brings all their other good works to naught!”

In due course we received an email from Pecunix enquiring as to the nature of their sin, and the Prof told them in no uncertain terms what was needed by way of redemption. Despite our vast readership which must now number in millions—well, give or take six zeros—we had no expectation that Pecunix would accede to our request. But we’ve observed that Pecunix, unlike most web sites, responds well to criticism, and where it’s justified acts swiftly to remedy the matter. So we were not too surprised when we received an email from the “main man” at Pecunix, an email that contained the joyous news that Pecunix had repented—and we’re always prepared to welcome a lost sheep back into the fold.

It seems that Javascript is no longer needed in order to create and access a Pecunix account. Well, since “doing is believing”, the Prof started his sentinel, booted his Tor proxy, woke up Firefox, and then wended his way to Pecunixie land, www.pecunix.com. He arrived in Pecunixie land to be greeted by a scene from the Lord of the Rings, for the inhabitants of that fair kingdom had come under attack from some dark force. But those brave elven folk quickly rebutted the attack, and after burying their dead, and repairing a few minor dents that the Prof had discovered in the walls of their citadel, the Prof was able to continue with his allotted task. And yes, with Javascript disabled he was able to create and access a Pecunix account. Well done Pecunix!

1mdc: the way of all flesh!

And while we’re speaking of Javascript, when we tried to logon to a 1mdc account recently the logon form seemed different and it was only when we had clicked in our PIN and got no response that we realized that the logon form was indeed different and, even worse, needed to have Javascript enabled. “Bugger,” we thought, “we’ve just persuaded Pecunix to abstain from using Javascript, only to find that 1mdc has gone the way of all flesh.” Then we espied a small link at the bottom of the page pointing to the old logon form that does not use Javascript, and we thought that all might be well. But when we progressed a little further through the logon process we discovered that on the new security form Javascript was required and there was no corresponding Javascript-free option available for those users with an interest in privacy. So as long as 1mdc does not provide a Javascript free interface we recommend that you bid farewell to the land of free e-currency swaps!

Even worse, 1mdc’s new logon procedure requires the user to collect a new security code from his email account every time he logs on. This is extremely cumbersome and does not offer an improvement in security. For example, suppose there is a key-logger on your machine. It will record your 1mdc password as you type it in. 1mdc then insists you log on to your email account to collect a one-time security code to complete the login. But the key-logger will also record the name of the email account and the password as you login to collect the security code. Once a hacker knows your email account and password he will be able to collect the new security code when he in turn tries to login. So in adding this extra step 1mdc have added not to the user’s security but to the user’s frustration.

Extra security requires that the user performs some qualitatively different task rather than just doing more of the same. So requiring the user to select some items using the mouse will defeat basic key-stroke loggers, though not mouse-click loggers. But clicking on items with the mouse can be achieved without the use of Javascript, so there is no need for an increase in security to compromise privacy. To defeat mouse-click loggers, though not video surveillance, the positions of the elements to be selected can be randomized, so that a hacker cannot work out what character a user selected from the position of a mouse click on the screen. To defeat one-off video surveillance then “windowed password entry”, in which a randomly selected set of characters from the password rather than the full password, is entered each time, can be used—as is the case with Pecunix and many online banks. For the highest level of security a PGP challenge can be employed. Even if Big Brother bugs the entire room and rebuilds the entire operating system to record everything happening in the machine, the user simply records the text that has to be signed, takes it away to some other computer that does not have, nor has ever had, an Internet connection, signs the text on that machine and then brings the signed text back to the original machine. All that Big Brother’s spyware will see is the signed text which can only be used for a one-off access to the account.

The net effect of 1mdc’s changes to the logon procedure is to push 1mdc into third place for both privacy and ease of use.

Results of the Privacy Stakes

So for all of you freedom loving folks the results of the “Privacy Stakes” are as follows: Pecunix romps home, an easy winner, well ahead of the rest. In second place, limping badly following a fall at the “US Treasury” spread jump, comes e-gold. There’s concern as to whether e-gold has a broken leg, and the vet is performing an examination at present. We’ll let you know in due course whether e-gold recovers, or has to be “put down on compassionate grounds”! Unfortunately, 1mdc doesn’t come anywhere at present. Unless and until it stops forcing its users to enable Javascript it’s a non-starter. But if it did, then it would jump into second place well ahead of e-gold!

Now, that’s not to say that Pecunix is perfect. Could we say Nearly Perfect Pecunix? No, not quite yet. They are some areas where we’d like to see improvements, and we’ll expound on those when we get down to discussing details. But in the broad sweep of things, in regards to its motivation, its responsiveness, and its technical expertise, Pecunix is by far the best bet at present for the privacy-minded.

Practicalities

Of course, there’s a problem in practice. E-gold has the largest share of the market, with 1mdc a good second, and Pecunix coming well behind (and most web sites will take no e-currency of any kind in exchange for their merchandise). It would be nice to see Pecunix catch up a little, but that all depends on whether they have the business acumen to match their technical expertise.

Of course, any new entrant to the e-currency marketplace will have the same difficulties as Pecunix in gaining market share. We had a chat with JG about it one day. The ideas we floated were a virtual debit card offered with the same degree of anonymity as the e-currency account—sign up once and you get both; a pass-through mechanism for e-currency payments so that a merchant could maintain a unified accounting system with a single e-currency issuer; bundling of the e-currency interface with some other more popular product; and a user-friendly implementation of e-currency micropayments. But discussing these ideas in detail is something we must leave for another day.

The Buyer

If you’re a Herr W.S. Blooer or a Miss D.S. Dent open an account with Pecunix. Then you can easily pay for your web site and other basic Internet services with very little risk of losing your anonymity.

If, like us, privacy is nice in principle but not essential in practice then open accounts with all three e-currency issuers. Keep most of your gold with Pecunix (it will not only offer you greater privacy, it will also offer you greater security) and keep some working capital with e-gold or 1mdc. 1mdc have a very nice free swap facility with e-gold and now also, in one direction, with Pecunix as well—we can say this of 1mdc, “When the good Lord was giving out business brains, 1mdc was at the head of the queue! It’s a pity they don’t have the technical expertise to match.” If the site where you want to make a purchase doesn’t support Pecunix then use e-gold or 1mdc instead. With e-gold there is a good chance that Big Brother will be monitoring your transactions, though your anonymity should still be reasonably safe with a good proxy chain. With 1mdc your transactions are probably safe, though there is a small chance that Big Brother with get a digital fingerprint of your computer, so your risk losing your anonymity.

The Merchant

If you’re a merchant then having so many different payment systems is a pain in the neck. Apart from credit/debit cards, you’ll be looking at Paypal (well until they freeze your account that is!) long before you’ll consider any e-currency as a payment method. However, if you’re in a niche business and privacy is particularly important to your customers then it’s worth your while offering Pecunix as a payment method. JG pointed out to us that its value is not only the extra business that it would generate. If you wax lyrical about Pecunix’s privacy features then you’ll provide a focal point to differentiate your business from that of your competitors—some of Pecunix’s “street-cred” in this area is likely to rub off on you!

Tiffium & Morphium – Bigus Brutium-Absentium Zonium

Micropayments, Micropublishing, and
E-Currency

The consequences of itemization and personalization—micropublishing—micropayment essentials—the telcos—the e-currency issuers—why anyone can have a go! ... Masochistium Clickium Hic!

Introduction

A micropayment is just a small payment, which, like its larger cousin, is handed over to a merchant in return for the supply of goods or services, and which, like its larger cousin, incurs an administrative overhead that is small relative to the transaction value. The cut-off level, at which micropayments transition into payments, is around a few dollars. Micropayments are ideally suited to the purchase of intangible web-based goods and services.

When JG gets going, he points out that if we look back over the past few decades there is one ever-present trend in retailing, a trend that consists of ever greater “itemization”. There was a time when many services were charged for at a uniform annual rate, even though different people made use of these services to different degrees. Goods were priced on the basis of what was needed to make a profit, on average, rather than by adding up the costs of production and adding on a percentage profit. In the absence of microelectronics and computers, measuring and recording service usage or constituent components was impractical. But now everything is being itemized—people charge for a service by how long it takes and the level of expertise of each person involved, and that newly installed water meter monitors how much water you actually use!

Personalization is a great driver in itemization. There was a time when people watched one channel on TV. Now there are hundreds, but viewers still have the inconvenience of manually changing from channel to channel. Soon a software agent will scan the Internet and download what it “knows” you like, and when you sit down to watch “TV” the software will assess your emotional state and present a personalised channel ideally suited to your current mood. Needless to say, you will only expect to pay for what you actually watch, and each programme will carry a separate charge.

The problem with itemization is how to pay for it. When there are many items delivered by the same supplier then the solution is easy. A computer records the items, adds-up the prices and you pay monthly, quarterly, or annually. The payment method used can have a high overhead which is easily absorbed, since the amount of each payment is relatively large. But what if you purchase just a few items of little value from a supplier—what if you read a few paragraphs of text in an online newspaper or magazine? For itemised charging to work in these circumstances the transaction overhead must be tiny. Welcome to the world of micropayments!

Micropublishing

Micropayments facilitate and are ideally suited to micropublishing: you can pay 20 cents for a recipe for some home-baked apple pie, or 10 cents for some rousing polemic against the war in Iraq.

Micropublishing is a potential goldmine, a vast untapped reserve. The conventional newspaper or magazine exists for the sole purpose that until now it has been impractical to pay for the individual articles you read from amongst the hundreds of articles that it contains. Perhaps you pay a few dollars for your magazine but only read 20%. But that means that 80% is wasted. In other words, for the price you’re prepared to pay the publisher could actually provide you with only that 20% and you’d still be satisfied, and he would pocket an enormous increase in profit. But it gets even better for the publishers, for the sum of the parts is far greater than that of the whole: publishers can charge a far higher price for articles when sold individually than when sold in bulk, as people are very insensitive to price when purchasing items of very small value—for example, for an article that should cost 2 cents most people would not bat an eye at paying 5 cents, but if the price of their newspaper jumped from $2 to $5 then they would be up in arms!

Another implication of micropublishing is the vast number of new content creators it brings into the marketplace. Very few people have what it takes to write a book, but many can write a few informative paragraphs on some topic in which they have some special expertise. Even if the number of potential readers is too small or the quality of the writing is too poor to merit conventional publication, search engines will find those paragraphs and micropayments will allow readers to pay for the pleasure, or otherwise, of reading the contents. Even though the Internet is overflowing with the most turgid prose, people still read it, and since people place at least some value on their time, they are effectively acknowledging that they are prepared to pay in order to read poppycock and piffle—after, all you’re reading this, aren’t you? A certain marketing man tells us that if you earn $30,000 a year, then you’re burning cash at the rate of about 6 cents per minute, even while you’re asleep, and so should be prepared to burn your hard earned dollars at a much higher rate to read something entertaining or informative while awake.

Micropayment Essentials

A practical micropayments system must embody two things:

  • Low transaction overheads
  • Ease of use

Low Transaction Overheads

Since the value of a micropayment is small, the overhead that the payment system incurs must be even smaller. This implies that transaction handling must be entirely automated—there must be no people in the loop. As long as people are only required in a support and maintenance role, then a very small profit made on each one of a very large number of transactions will pay for those people, and will lead to a profitable business.

Automatic transaction handling means that transactions must be irrevocable. Any system that allowed chargebacks would require manual intervention for a certain fraction of the transactions and this cost overhead would be prohibitive.

Ease of Use

The key issue as far as users are concerned is not security but ease of use. If a user is paying for each link that he clicks on then it is essential that he does nothing more than “click on that link”. If he has to do anything else, such as enter a password or even press a confirmation button, then the micropayments system is not viable. For a system to work there must be no alteration in the user’s browsing habits!

In practice, a site offering a usable micropayments system might simply add the price of the link to the anchor text. For example, if you were paying for this article you might see “Micropayments, Micropublishing, and E-currency ($1)”—okay, let’s be realistic (1c)! You’d click on the link, this page would appear, and one cent would be automatically deducted from your micropayments account, without any intervention on your part whatsoever!

Price Range Colour Coding

The first problem with the above solution is which currency to use. While gold is an obvious choice, it’s no use using milligrams of gold to display the price as the average punter has absolutely no feeling for what it’s worth!

As web users have many different national currencies a more generic approach would be to divide payments into a fixed set of ranges, and then code the payment into the anchor text using a small icon of a particular colour. A standard payments table would then show the approximate payment range based on the current gold price that each code represented in each national currency. For example,

  • Red > 2$
  • Orange 1-2$
  • Yellow 50 cents – 1$
  • Green 10 cents – 50 cents
  • Blue < 10 cents

would give a user immediate feedback on whether the price range was acceptable. A percentage figure contained within the icon could be used to indicate the exact price based on the range, so “blue 10%” equals 1 cent, “yellow 50%” equals 75 cents, and “red 500%” equals 10$.

When prices are small, the exact price becomes unimportant; a user just wants to ensure that he is not paying an unexpectedly large amount for an item. It is very easy to check colour coding that is embedded in a link. A user might decide, “I’m prepared to press on anything that isn’t red; if it’s red then I need to pause to see if it’s really worthwhile.”

So we feel that, with a bit of work, a simple and internationally useful system could be devised that would allow users to check the price in a nearly effortless fashion.

Security

Security is of very little importance when it comes to micropayments. Let’s take an example. Suppose you spend $150 a year on micropayment purchases and that on average once a year someone breaks into your micropayments account and appropriates the balance which averages $5. Would this “extra expense” be worth it for the convenience of simply being able to click on a link in order to make a payment, rather than having to type in a password every time? The answer for almost everyone is a clear “yes”.

The only thing that matters for users is the ability to place a limit on their possible losses from a micropayments system that operates at a comparatively low-level of security compared to those designed for standard merchant purchases. As long as users can set the limit according to how risk adverse they happen to be and the degree of inconvenience they find in frequently topping-up their micropayments account then all will be well.

Account Characteristics

There are many ways in which a micropayments system could operate. In this section we’ll outline a possible mechanism for operating a micropayments system and the sort of characteristics that an account might possess, demonstrating, we hope, that it’s relatively easy to satisfy the needs and address the potential concerns of user, merchant, and micropayment systems service provider alike.

Initialization

When the first payment on a site is made the merchant transfers the user to a page on the micropayments system’s web site. The user enters one very simple password, and presses OK. The form is sent to the micropayments system service provider (MSSP), who then gives the merchant permission to draw funds from the user’s account for a specified period of time, up to a certain limit, both of which were set by the user when the account was created.

As the user browses the site and clicks on links that incur payments, the merchant keeps a total and at intervals sends the total to the MSSP who debits the user’s account, credits the merchant’s account, and charges one or both a small commission.

Even though the amount of each payment is small no significant additional web traffic is generated, since the merchant simply accumulates the amounts owing until either the limit is reached, the user has stopped generating additional payments for some period of time, or the maximum period of time over which the merchant can collect payments has expired.

The merchant never knows the identity of the user since the merchant generates a payment identifier at the beginning of each session which is included in the form that the user sends to the MSSP, and which is returned by the MSSP to the merchant along with the payments limit and timeout information.

The merchant uses a cookie on the user’s computer to store the payment identifier, so that the merchant can separate payments into separate streams with a cumulative total held in the merchant’s database against each payment identifier (if the user deletes or modifies the cookie, the total owing is not lost, and a new session is started should the user continue to click on payment links).

For efficiency, the merchant could settle up with the MSSP on a daily basis, sending to the MSSP a single file containing a complete list of all payment identifiers and corresponding payments. The MSSP could then update the corresponding user accounts.

Termination

On a publicly accessible computer it would be important for the user to either delete the session cookie or indicate to the merchant that the session was at an end by pressing a “no more payments” button on the merchant’s site. But the potential problems here are less serious than those associated with sessions left open on a financial site where the sums available to be appropriated would be much higher.

Account Limit

When creating an account with the MSSP the user sets a limit on the maximum amount that can be in the account at any one time—the MSSP might default this to some low value, and might even set an absolute maximum. The account limit represents the maximum amount that the user could lose if security is breached. If the user attempts to fund his account above this limit then the funding transaction is rejected. If the user changes the account limit then warning messages appear stating that this is a low security account and the user should not put in it more by way of funds than he’s prepared to lose by way of peculation.

Timeout

Each session with a particular merchant could be time limited. Before the time limit expires the merchant must terminate the session and send a demand for payment to the MSSP. If access is typically from a home based computer and the user does not delete selected cookies then the timeout could run into weeks, so that the merchant steadily accumulates small amounts as the user browses the merchant’s site. If access is typically from a publicly accessible computer and the user spends a few seconds checking some stock market prices, then the timeout could be in minutes. There is a trade-off between storage and communications overheads. Short timeouts require the merchant to generate much more web traffic to and from the MSSP. Long timeouts require the merchant to maintain long lists of payment identifiers and associated payments owing. Irrespective of the user specified timeout, the merchant can terminate the session at any time, forward the current amount owing to the MSSP, and require the user to start a new payments session.

Single Payment Limit

The user could place a limit on the maximum value of any one micropayment. A user who did not want to spend more than 50 cents when clicking on any one link without specific authorisation could say so, ensuring that he is not charged $50 for a miss-colour-coded payment link (though the enforcement of this rule would be up to the merchant if only aggregate totals are sent to the MSSP).

Spend Rate

The user could limit the total amount that can be spent in any particular time period, say a day or a week. When starting a new session the limit sent to the merchant would be the lesser of the account balance and the difference between the spend rate less the amount already spent within the current time period.

Approved and Excluded Merchants

As micropayments systems lend themselves to paying for articles or downloading images and music, and users tend to have favourite sites, a user is very likely to use the system frequently, but with only a small number of merchants.

The user could specify that micropayments can only be made to, or can never be made to, certain merchants. This would allow the user the convenience of one-click micropayments for most purchases, while being able to revert to the “always enter a password” mode for others.

Account characteristics, such as the timeout, the single payment limit, and the spend rate could be customized for each approved merchant.

Record Keeping

Given that the amounts spent are small there should be no need for a conventional transaction history detailing the name of every link that the user has clicked upon and its cost. We suggest that the following information about a session should be sufficient for the user’s purposes:

  • Merchant’s name
  • Web address
  • Date
  • Time of first micropayment
  • Time of last micropayment
  • Total number of micropayments
  • Total cost of micropayments
  • Average cost of micropayments (derived)
  • Cost of highest value micropayment

The merchant’s name, web address, date and times would be sufficient to raise suspicion if anyone had gained unauthorised access to the user’s password. The number and costs of the micropayments would be sufficient for the user to judge whether he was getting value for money, and would make it easy to perform inter-site comparisons for the respective costs of accessing similar material.

By restricting records to totals, averages, and outlying values in this manner the storage requirements for those merchants who have millions of users browsing their sites on a daily basis would be kept to a minimum.

The Telcos

The Telcos have not yet developed useful micropayments systems. Typically, a merchant places a code against each item to be purchased. The user sends the code by SMS text or touch tone to the telco who returns an authorization code which the user then enters into a merchant form. This method is even more cumbersome than password entry, as two codes have to be typed in and there is a delay while the item code is authorized. It is totally unsuitable for micropayments.

However, it would not be difficult to automate this procedure. A Bluetooth USB fob plugged into the computer could talk to a Bluetooth enabled phone, and software could then send the codes back and forth automatically. When suitably equipped mobile phones reach a critical mass we can expect the Telcos to move into the micropayments marketplace.

The E-currency Issuers

It would not be difficult for an e-currency issuer to add a micropayments service to its existing portfolio. But the big three still require the tedious entry of passwords no matter what the value of the payment. The potential revenue from this market is vastly more than that available from either asset storage or conventional merchant sales: the reason is simply that in the long-term almost everything on the Internet is likely to come with a small price tag attached—this is the logical end point of itemization. It would solve the pressing and ever-growing problem of how to pay for the infrastructure that is needed to cope with ever higher bandwidth services—it’s a better solution than the “two-tier Internet” which is the only alternative on offer.

If they don’t get their collective acts together soon the e-currency issuers will be overtaken by the Telcos. And a micropayments service provides an ideal opportunity to be number one: even if the market is small to begin with, the e-currency issuer who is first on board is likely to retain the lion’s share of the market as it grows, and the “johnny-come-lately”s will have the difficult task of playing catch-up. Most of the potential merchants in the micropayment market place are unlikely to be using e-currencies at present, providing an ideal marketing opportunity for either Pecunix or 1mdc to claim the blue ribbon within this sector.

Because of the intrinsically lower security requirements of micropayments systems it would be unwise for an e-currency issuer to just add micropayment functionality to its existing service. That might damage its reputation for security in the asset holding and conventional merchant payment sectors. A sub-brand would reinforce the main brand while providing a sufficient degree of separation so that users would appreciate that the two payment systems offered very different levels of security—anyone for a Pecunix-Lite or a 0mdc?

An empty niche

It’s arguable whether there are any micropayment systems available at present that are easy to use for both merchants and their customers, and which provide a clear separation of payment and content—we don’t like what we’ve seen. And there are certainly no anonymous micropayment systems at present. So there is a definite niche here to be filled by anyone who is prepared to make a modest investment.

You don’t have to be an existing e-currency issuer to develop a micropayments system. You can take a leaf out of 1mdc’s book and piggyback your system on top of Pecunix, e-gold, or even 1mdc itself. With the interfaces provided by these merchants it’s easy to bolt on additional services, and since the big three show no interest in micropayments at present there’s a window of opportunity for any small enterprising organisation to make its mark. But don’t delay. It won’t be too long before the e-currency issuers, and indeed the Telcos, realise that they’re missing out on a very big opportunity, and start mining this seam of pure gold!

Tiffium & Morphium – Bigus Brutium-Absentium Zonium

Where E-Currency and Digital Cash Meet

Is digital cash so different from e-currency?—one needs an account and the other doesn’t—but what about transaction history?—nearly perfect processing! ... Masochistium Clickium Hic!

Is Digital Cash so different from E-Currency?

As we said in a previous blog entry anonymous digital cash is a wonderful thing. Now while conceptually it’s quite different from e-currency, when you look at how it works in practice the infrastructure begins to look very similar. For anonymous digital cash the double spend issue forces each exchange of a note to be verified by the issuer. So the issuer must be contacted. But this is just what every e-currency transaction involves; the e-currency issuer must be contacted. So while there are clear marketing advantages to promoting digital cash as a separate entity, it’s worth asking if an e-currency issuer could provide the same level of privacy as that provided by digital cash by altering the way in which it operates.

(We should say that there are some quasi-anonymous offline digital cash systems that don’t involve devices like smart cards, and which are anonymous in the case of no double spends. But if someone copies your digital cash note unbeknownst to you and spends it, then you and the transaction in which you spent the note would be identified. Apart from being dubious in respect of privacy these systems also assume that the possibility of being caught will prevent people from making double spends. Hmm! If you could make a few million on your computer right now, spent it, and only possibly be caught in the future would you do it? You wouldn’t. We wouldn’t. But our guess is that there are a sufficient number of people who would be tempted so as to make the system unworkable!)

One needs an Account, but the other doesn’t!

The most obvious difference between e-currency and digital cash is that to use e-currency you need to create an account whereas to use digital cash you don’t—you just need to verify each note you receive and this you can do anonymously. Now when an account is created some e-currency issuers, such as e-gold, require personal information to be entered, while others, such as Pecunix, do not. So while creating an account might be an inconvenience, it need not necessarily reduce your anonymity if you choose the right e-currency issuer—the Proxy chain that you use to verify a digital note is the same proxy chain that you use to create an anonymous e-currency account. So in respect of account creation there need not be any diminution in anonymity.

But what about Transaction History?

With digital cash there is no record of transactions as a note is passed from one person to another. But what about e-currency? Well if Tiffy pays Morpheus’ Undies Emporium $100 for her French frillies, the record of the transaction might look like “20-07-06 12:34 Transfer of $100 from account 827526 to account 927827 Order #: HG728”.

Now what information does the e-currency issuer need to keep for business purposes—rather than for Big Brother purposes? Well, the delightful and simplifying aspect of e-currency is that transactions are non-repudiable, so from a business point of view the e-currency issuer needs to keep no information whatsoever. Before and after the transaction the amount of e-currency issued remains exactly the same. From the point of view of external audit what matters is the match between the total e-currency issued versus the physical reserves in precious metal. A transaction in which the e-currency issuer buys or sells precious metal needs to be recorded. The cumulative commission charged on all e-currency transactions needs to be recorded. The current credit or debit balance on each account needs to be recorded. But records of the individual transactions in which e-currency moves from one account to another serve no useful business or auditing purpose.

So why do e-currency issuers keep transaction records other than to act as unctuous servants of Big Brother? Well, Tiffy wants a record of what she spends and Morpheus’ Undies Emporium wants a record of what it receives. Yes, but why don’t they just keep their own records? Well, there’s no good reason why not. Let’s suppose Tiffy makes the transaction “20-07-06 12:34 Transfer of $100 from account 827526 to account 927827 Order #: HG728”. When the e-currency issuer prints out the confirmation web page on Tiffy’s screen, Tiffy can save it to disk if she wants to keep a record. And Morpheus’ Undies Emporium will receive a POST transaction or an email containing the same information plus its order number all hashed together for the purpose of verification.

So an e-currency issuer who respects the privacy of its users could offer within its accounts configuration section a “tell no tales” check box. If ticked then the transactions for that client are never recorded. If, for example, Tiffy had ticked the box but Morpheus’ Undies Emporium had not, then the Emporium’s transaction log held by the e-currency issuer would contain the entry “20-07-06 12:34 Transfer of $100 from anonymous to account 927827 Order #: HG728”. Since the Emporium will have all Tiffy’s details stored in its own database against its own order number the Emporium has full details of the transaction.

This “tell no tales” facility makes an e-currency issuer’s database less of a honey-pot for the sort of mass surveillance that is in favour with today’s Big Brothers. Because an e-currency issuer’s database contains records in a uniform format it can be read and readily dumped into a “personal-networks analysis” computer program, whether one run by Big Brother (as seems to have happened recently in the case of e-gold) or Big Business. If one side of a transaction is suppressed then Big Brother will have to trawl through the databases of individual merchants. This is time consuming and ensures that Big Brother focuses on a small number of criminal suspects rather than playing peeping-tom and ogling the financial transactions of the population at large—well, at least until the metadata web is rolled out!

An e-currency issuer could provide a radio button in the account configuration section (or indeed on a per transaction basis):

  • Public
  • Private
  • Not on my side
  • Not on both sides

This provides the user with a range of options: “private” would be the default, implying that transactions are recorded and the transaction history is made available to both parties to the transaction; “public” would mean anyone could view the transaction history, an option that may be useful to some public bodies and organisations; “not on my side” would mean that the user’s side of a transaction is never recorded, but the other side is recorded as “private” or not at all depending on the other side’s preferences; “not on both sides” would mean that no record of the transaction is kept, with the implication that if both parties do not have the same setting then the transaction is refused. The “not on both sides” option should not cause any difficulties for merchants or buyers alike, since each gets information about each transaction by a web POST or by email, which allows them to update there own records. So with the “not on both sides” option in place e-currency effectively provides the same degree of privacy as digital cash. If Big Brother cannons through the door all he will find is lists of account numbers with current balances against them, but no information as to how those balances got to be that way, no information as to who has been doing business with whom.

The only downside we can see to the “not on both sides” option is from the point of view of buyers and small merchants. Larger merchants would automatically use the web POST mechanism to insert details of each transaction into a database in real time, and they could run their own reports against this database. But buyers and small merchants who rely on email notifications would just have a collection of emails from which they would have to manually extract the information.

But can we do better? Can we live in a perfect world? Yes we can! The e-currency issuer could record all transactions so that a user could see what’s been bought and sold, but could still prevent Big Brother from getting access to the data, even when Big Brother turns up at the door with a warrant. How is this magic accomplished? How could the e-currency issuer smile sweetly and say to Big Brother, “There is our transaction database, 100 Gb in size, containing complete details of every transaction, including IP addresses, going right back to the year dot. Take a copy. Do as you please. We have nothing to hide?”

Well, an e-currency issuer that allows users to store PGP public keys with their account details could very simply encrypt each user’s transaction with that user’s public key and store the encrypted transaction in its database. Then the only person who could view the transaction history would be the user, as only the user would have access to the private key. Imagine the joy of being a fly on the wall when Big Brother arrives to rifle the database of such a privacy-friendly e-currency issuer!

To view the transactions a user would first download encrypted transactions to his computer, with neighbouring transactions delimited by a separator. A simple program—one provided by the e-currency issuer or available on the Internet for free download—would then take each encrypted transaction in turn, decrypt it to recover the plaintext, and then concatenate the results together to reconstruct the original transaction log on the user’s computer.

Nearly Perfect Processing!

Now businesses are obliged to comply with the law, and the law invariably obliges them to make their records available for inspection. However, often the law does not stipulate what records a business needs to keep. Even if a business wishes or needs to keep adequate records for the purpose of external audit these records can often be uninformative as far as Big Brother is concerned. So if you, dear reader, run a business we suggest you divide your data into three categories: what you need, what the law requires, and what you keep for your customers’ convenience. For data in the latter category give the customer the option of not having it recorded or of having it encrypted with the customer’s public key. You could always sign the plaintext with your private key before encrypting it with the customer’s public key, so the customer would have evidence that you created and approved the transaction details should he ever need to raise a query in the future.

The nice thing about encrypting client transactions with the client’s public key is that even businesses operating onshore may be able to maintain client confidentiality in the face of warranted searches of their premises while still complying with the law. For businesses that operate offshore there is always the risk of Big Brother gaining access by illicit means, so the same principle applies. If transactions are always encrypted with one-time-keys when sent over the Internet and always encrypted with a public key whose private partner is unknown to the business when written to disk, then the plaintext is only accessible in memory for a very short period before being consigned to oblivion. An example of perfect transaction processing? No! Of Nearly Perfect Processing! Yes!

Tiffium & Morphium – Bigus Brutium-Absentium Zonium

Digital Cash: Or how to make Big Brother ...

How digital cash works—why security is not a problem—why privacy is unexcelled—the obstacles—digital cash as an add-on for the e-currency issuers. ... Masochistium Clickium Hic!

The Prof launches ProCash

What’s the most anonymous form of transaction? That’s easy. It’s a transaction that involves cash. True, a note has a serial number on it, but no one records that serial number as the note passes from person to person—at least not yet, and the story about a future that contains RFIDied notes owned by RFIDied people must wait for another day.

So is there a digital equivalent to paper notes and metal coins? Well, “yes” and “no”. “Yes” in the sense that some people have created digital cash systems, but “no” in the sense that very, very few merchants are prepared to accept any kind of digital cash. The main reason is that no candidate digital cash company has been prepared to burn vast sums of cash—the ordinary kind—to promote the system until it reaches a critical mass.

Various types of digital cash systems have been devised, some anonymous and some not, some online and some offline. We don’t approve of those systems make use of smart cards or similar devices as there is no way to verify that such devices preserve the user’s privacy. And, of course, we certainly don’t approve of those systems deliberately designed to identify their users!

If an anonymous digital cash system became widely used it would be the single must important factor in preventing Big Brother from snooping on people’s financial affairs. It’s actually very easy to create and issue digital cash. Let’s suppose that the Prof decided to set himself up as an issuer of anonymous and untraceable digital cash using the brand name ProCash. Then all he needs is a PGP public key pair. He generates a unique set of serial numbers and allocates various amounts of either fiat or metal currencies to those serial numbers. For example, here are three digital notes:

Digital Notes

ProCash 183873 $100
ProCash 258323 £100
ProCash 397625 100 grams gold

Sitting as character strings on the Prof’s computer they’re worthless, but once the Prof signs them with his private key then they are as good as...as good as the Prof’s word. They become like IOUs.

Suppose I’m a merchant running Morpheus’ Undies Emporium and I sell my silky merchandise in return for ProCash USD. Tiffy espies something nice in my virtual window and wants to purchase something French and frilly for ProCash $100—expensive, non Madame, zit’s cheap at the price! Well, Tiffy pays ProCash $100 in some suitable form plus a small commission, and then ProCash issues Tiffy with a ProCash note “ProCash 183873 $100”.

Now the first thing to note is that Tiffy can be sure that the note is genuine. No one can forge ProCash notes since no one has access to ProCash’s private PGP key—and Tiffy can verify that the note is genuine using ProCash’s public key. Now if Tiffy changes her mind—not very likely with silk in sight—she can return the note to ProCash and get $100 in exchange. The risk here is no more or no less that than encountered in dealing with any financial institution, be it an e-currency issuer or a bank.

So far so good. But the Prof was not born yesterday, or the day before that for that matter. The Prof realised that while no one can forge a ProCash note, anyone can duplicate it. In fact Tiffy might duplicate it millions of times. The result would be that the ProCash note would be subject to inflationary pressures that would make the President of Mupoobay Land jealous, and ProCash would quickly go bust. So in the T&Cs of ProCash there is a little clause that says that where multiple instances of the same note are passed to ProCash for redemption only the first instance will be honoured. It is the responsibility of the recipient of a note to ensure that it has not been duplicated. With this clause in place the Prof gets around the “double spend” problem that dogs all digital cash systems. He simply keeps a list of the valid notes in circulation and removes them from the list as they are redeemed.

Now Tiffy, in the course of purchasing that new acquisition to adorn her nether regions, sends her note to me at Morpheus’ Undies Emporium. Now I have a little problem here. ProCash knows the note is valid; Tiffy knows the note is valid; but I don’t. What if Tiffy had made millions of copies and had been purchasing undies left, right, and centre with the duplicates. What if when I go to redeem the note ProCash says “tough cheese”!

Now of course the Prof had the foresight to help me out in this little dilemma. And to do so he instituted a free note swap. Anyone who possesses a ProCash note can send it to ProCash and if the note is valid ProCash will issue for free another note of exactly the same value. So now when Tiffy sends me the note, but before my web site tells her that the note has been accepted, I send the note to ProCash. ProCash issues me with another for the same value. Now I know that I have a valid ProCash note for $100, so I can wrap those undies in some nice pink tissue paper and dispatch them to Tiffy post-haste.

Since all these operations can be automated a digital cash system is easy to set up and to use.

Security

There are no special issues with digital cash as far as security is concerned. Given the rapid turnover of digital cash one would expect it to be fully backed by assets of equivalent value.

Privacy

This is where it gets a little more interesting. Let’s say that Tiffy purchases her note for some e-currency issued by ECI (yes, it’s fictional). ProCash might record this as: “ProCash 183873 $100 for $101 from account Tiffy at ECI from IP 121.45.98.198”. This record contains quite a lot of information about the transaction. In particular, it lists the source of the funds.

When I do a swap the information recorded might be: “ProCash 183873 $100 swapped for ProCash 832637 $100 from IP 76.276.28.176”.

When I buy a box of silk undies with ProCash I pass the note on to the supplier who in turn passes in on to someone else. Eventually, the note will be redeemed, which ProCash might record as: “ProCash 849898 $100 for $100 to account JG Publications at ECI from IP 97.833.973.834”.

So the transaction log held by ProCash might look like:

ProCash Transaction Log

01-07-06 ProCash 183873 $100 for $101
From account Tiffy at ECI from IP 121.45.98.198

02-07-06 ProCash 183873 $100 swapped for
ProCash 832637 $100 from IP 76.276.28.176

05-07-06 ProCash 832637 $100 swapped for
ProCash 636394 $100 from IP 375.48.376.26

10-07-06 ProCash 636394 $100 swapped for
ProCash 849898 $100 from IP 486.376.927.27

15-07-06 ProCash 849898 $100 for $100
To account JG Publications at ECI from IP 97.833.973.834

Now you can see why the Prof is beginning to spoil Big Brother’s plans for mass surveillance. During the intermediate steps when notes are exchanged the only information that is available about the transaction is the IP address used to swap the note, and this could be hidden behind a proxy chain making the participants in the transaction anonymous.

However, the Prof respects people’s privacy so he only keeps information that is needed for business purposes. There is no need to record the IP addresses associated with the swaps: ProCash receives a note, sends a new note, and the recipient presses a button to acknowledge safe delivery of the new note. Equally, as input and output transactions are non-repudiable there is no need to record the IP addresses once the transactions have been completed. So the transaction log held by ProCash might look like:

ProCash Transaction Log

01-07-06 ProCash 183873 $100 for $101
From account Tiffy at ECI

02-07-06 ProCash 183873 $100 swapped for
ProCash 832637 $100

05-07-06 ProCash 832637 $100 swapped for
ProCash 636394 $100

10-07-06 ProCash 636394 $100 swapped for
ProCash 849898 $100

15-07-06 ProCash 849898 $100 for $100
To account JG Publications at ECI

But Procash has no interest in recording information about what is swapped for what. Just the status of the individual notes is all that is required. So at the beginning of the transaction chain ProCash’s business records might look like:

Business records at beginning

01-07-06 ProCash 183873 $100 for $101
From account Tiffy at ECI

ProCash 183873 $100 Issued
ProCash 832637 $100 Unissued
ProCash 636394 $100 Unissued
ProCash 849898 $100 Unissued

and when the chain is complete:

Business records at end

01-07-06 ProCash 183873 $100 for $101
From account Tiffy at ECI

15-07-06 ProCash 849898 $100 for $100
To account JG Publications at ECI

ProCash 183873 $100 Redeemed
ProCash 832637 $100 Redeemed
ProCash 636394 $100 Redeemed
ProCash 849898 $100 Redeemed

All that has happened is that the issuing and redeeming transactions are recorded and the individual notes move from a status of “Unissued” to “Issued” to “Redeemed”.

If ProCash wishes to boost its credentials by employing an external firm of auditors to report on its business, everything that an auditor is interested in is present in the business records. All flows of funds into and out of the business are recorded so changes in assets can be determined. A complete list of all notes currently issued is available so the current liabilities of the business can be calculated.

But we can do even better as far as privacy is concerned. What if a user is worried that ProCash may be a Big Brother sting operation and is recording IP addresses. Now there is nothing to stop anybody setting up as an independent digital cash swap shop. Let’s say The Swap Shop sets up in business as an independent verifier of ProCash notes. So instead of swapping my note directly with ProCash I can send my note to The Swap Shop. The Swap Shop sends the note to ProCash, which sends a replacement note back to The Swap Shop, and then The Swap Shop sends it to me (for a small commission paid in ProCash). So if ProCash were a Big Brother sting operation the IP addresses that it would record would be those of The Swap Shop, and completely uninformative. In practice The Swap Shop will keep a pool of notes of different values which it knows to be valid, so when it receives a swapped note back from ProCash it will not send that note to its customer, but instead one of equivalent value drawn at random from its pool.

Clearly there can be many swap shops, and, like newsagents that only need to record how many newspapers they’ve sold, all that these swap shops need to do is to record how many notes they have verified. Even if The Swap Shop were collaborating with ProCash in recording IP addresses, others would not. So the anxious whistleblower could swap a note any number of times with different swap shops to make sure it was not traceable by Big Brother. The integrity of swap shops is easily monitored since it’s a simple matter to select at random notes received from a swap shop, and verify them directly with ProCash. If ProCash concluded that the note is not valid because it had been double spent then the business of the associated swap shop would collapse overnight. So in this scenario we could expect to see a number of swap shop verifiers spring up, who regularly verify that swap shops are not cloning notes. New swap shops would be regarded with suspicion at first and would initially have to work at low volumes and with small denomination notes until their trustworthiness was established. Swap shop verifiers would be in a position to offer insurance policies against fraud by individual swap shops so that customers would be able to receive compensation in the case of fraud. Since swap shops with the highest rating would attract the most business it would be in their interest of swap shops to encourage verification by well established verifiers.

Secondary currencies can be derived from ProCash. For example, 1mdc receives Pecunix or e-gold and then issues a 1mdc equivalent in return, an equivalent that can subsequently be used in transactions. This makes 1mdc a secondary or derived e-currency. Whereas Pecunix and e-gold have the overheads of storing and auditing physical gold bars, 1mdc is an entirely electronic operation. In the same way a digital cash reseller can receive a ProCash note and issue its own digital cash in return without incurring the overheads associated with issuing and redeeming that ProCash incurs. And just as we would like to see many secondary e-currency issuers like 1mdc to provide more opportunities for privacy so too we would like, in this hypothetical scenario, to see many secondary currencies derived from ProCash. Secondary currencies are useful in distributing the processing burden of verification. ProCash is likely to focus on issuing higher value notes, leaving it to derived secondary currencies to produce notes of smaller value. In practice, the functions of swap shop and secondary currency issuer are likely to be combined in many cases.

With digital cash we have the best of both worlds. Good business records for the purpose of audit, but no records of cash swaps. So transactions using digital cash can be just like their paper cousins: invisible to Big Brother’s Sauron-like eye!

Obstacles to overcome

So digital cash is easy to set up, is as secure as an e-currency, and provides an exquisite level of privacy. But there are two problems.

The first problem is the same as that of any e-currency that’s a new boy on the block: without a substantial market share merchants won’t offer it as a payment method; and without it being readily available as a payment method it won’t increase its market share. One way around this obstacle is to burn a modest amount of capital in return for a high degree of penetration in specific niche markets. For example, Internet gaming already has some niche payment systems that aren’t used elsewhere. If you can add enough niches then in time your digital cash may become mainstream, but it’s very hard work.

The second problem is that the degree of privacy that digital cash affords causes Big Brother to ..., and to assuage his suffering he is likely to take drastic action, like banning all merchants operating within his domain from offering digital cash as a payment method. The way around this obstacle is a third-party payment chain, which works well and is reasonably cost effective for non-repudiable transactions, but that’s for another day.

Digital Cash as an E-currency Add-On

There is one group of businesses that are ideally suited to offer digital cash, and they are the existing e-currency issuers. The important factor here is the difference between setting up a digital cash operation from scratch and the cost of providing it as an additional service for an existing e-currency issuer. The marginal costing to an e-currency issuer is nominal. The issuer already has the technical infrastructure in place. The programming requirements are negligible. More importantly, if the e-currency issuer insists that the purchase and redemption of digital cash takes place using its own e-currency, then the process simply becomes one of internal bookkeeping. The marginal cost of issuing, swapping, or redeeming is no more than the cost of a few web page accesses and the running of a few scripts against a database. Hence, the commission charged for issuing a note can be very small.

There are a number of advantages for an e-currency issuer in adding digital cash to its portfolio. We had a chat with JG about the marketing potential of digital cash. We came up with the following ideas.

Digital cash becomes a marketing plus for an offshore business that, like Pecunix or 1mdc, is selling itself on its privacy credentials. It provides a “golden opportunity”—sorry for the awful pun—for an e-currency issuer to overtake e-gold. Much as we like e-gold for boldly going where no financial institution had gone before, we feel it has probably made a strategic mistake by being based onshore. It’s highly improbable that it will ever offer digital cash, and indeed it has already made negative comments about digital cash on its web site. And the US government would go “ballistic” if e-gold ever attempted to do so. Given the fractious relationship that already exists between e-gold and the US government, e-gold seems very keen to calm the waters. The danger for e-gold is that it is forced to operate on a know-your-client basis or even to become another Paypal. Even if it retains the distinction of offering non-repudiable transactions it would be operating on the same ground as the big boys in the world’s financial marketplace. These players have vast amounts of cash to burn by way of advertising and promotion and could easily step in and offer alternative e-currencies that would rapidly eclipse e-gold. The most likely scenario would be that after a slide in its fortunes e-gold’s assets and technology would be acquired by a major player that would then market them under its own brand name—anyone for MicrosoftGold! So should e-gold be forced to operate on a know-your-client basis its star is likely to fall very rapidly.

So for those e-currency issuers who operate offshore there is the opportunity for future press coverage to read “while Pecunix, 1mdc, and e-gold all offer e-currencies, in addition Pecunix and 1mdc offer digital cash”. Think of the impact that this sort of statement makes on newbies to the e-currency market. It makes Pecunix and 1mdc seem more substantial than e-gold.

People with an interest in privacy will be attracted to digital cash so it provides a new stream of revenue. As there is no digital cash system of comparable size to the e-currency issuers it is easy for an issuer to leverage its position within the e-currency market place to become number one in digital cash. And we all know the marketing advantage of being number one irrespective of the quality of the product on offer—remember VHS and Betamax? How important digital cash will be in the world’s financial system in the long term is impossible to forecast, but if it does take off in a big way then the small cost of positioning oneself as number one right now could yield an “Intel” or “Microsoft”-like payback.

If customers with an interest in digital cash wished to have notes issued or redeemed then they would need to open an e-currency account with the issuer, which would boost the issuer’s mainstream e-currency business—once someone has gone to the trouble of opening an e-currency account and has put some funds in it they are likely to use it. Therefore the introduction of digital cash would provide a means of taking market share away from competitors.

The same script provided by an issuer to a merchant for a customer to make an e-currency purchase could also be used to make a digital cash purchase. This would be attractive in gaining new business as the merchant gets both an e-currency and a digital cash payment system for the same amount of effort.

While many of these prospective benefits are small we feel that in total they probably outweigh the marginal cost of adding digital cash to an existing e-currency operation.

Tiffium & Morphium – Bigus Brutium-Absentium Zonium

Can you trust the PGP Corporation with your Data?

What’s gone to that great computer room in the sky—why relativistic software that would do Einstein proud doesn’t always please—why what goes in doesn’t always come out, easily—why size really matters, honestly—why Luigi is invoicing the PGP Corporation for his doctor’s bill—why the PGP Corporation could do a great deal better! ... Masochistium Clickium Hic!

The Great Computer Room in the Sky

Now once upon a time our friend Luigi was a fan of the software produced by the PGP Corporation. He would use the latest version of PGP Desktop Professional, currently version 9.0, to store his data on an encrypted virtual disk.

After having suffered a few major data losses early on in his computer career Luigi had become careful. At the end of each day he would perform an incremental backup of his data to a USB memory stick containing a second PGP virtual disk. At regular intervals he would back-up his data to a PGP self-decrypting archive stored on an external disk that he kept onsite, and less frequently from that external disk to an external disk that he kept offsite (he even used a pair of disks for offsite backup so that his data was always physically present at two different locations at any one time). And he maintained hashes of his backup files and tested them regularly to ensure that they had not become corrupted. All in all, Luigi had the makings of a good systems administrator.

So when one day a thunderstorm interrupted his uninterruptible power supply and the ghost in his machine left for that great computer room in the sky, Luigi was annoyed but not despondent. After all, with backups generated by such a sterling product developed by such a large and reliable organization as the PGP Corporation what was there to worry about? Ah, what indeed dear reader!

Relativistic Software that would do Einstein proud!

Let’s join Luigi as he begins his quest for the holy grail of restored data.

Now-a the most-a recent backup is-a my onsite-a backup. So let’s-a copy the SDA to my new computer. Wow! It’s-a big file. ... Takes-a the time.

Now double click on the SDA and off-a we go. Hey, where’s-a the password screen? Maybe I no double click proper. So let’s-a press Enter instead. Nothing! Oh! Bugger-a! Computer’s-a locked up. Okay, so try Ctrl-Alt-Del to reboot. Ah! Shit-a! Even Ctrl-Alt-Del not-a work. Try hard reset.

Run SDA again. Nothing! Nothing! Nothing! Wait a few minutes. ... No! It’s-a still doing nothing. SDA must-a be corrupt. Have to go get the offsite backup. What-a pain!

Some days passed—dataless days for our valiant hero—before he got hold of the offsite backup. Let’s join him again.

I-a lost-a whole month of data. It-a just as well I keep-a the offsite backup or I lose everything. Okay, let’s-a double click on the offsite SDA. No! No! No! I don’t believe it. Nothing! Computer frozen again. What’s-a the odds? Two-a backups corrupted, even though I-a test each one after I create it! Very suspicious. Check-a the hash I-a make of offsite SDA. I don’t believe. Hash fine. Offsite backup not corrupted. Check-a the hash I-a make of onsite SDA. Again, hash-a fine. Onsite backup not corrupted. Ah! Maybe PGP software corrupted. I-a reinstall and try again.

Shit-a! Shit-a! It-a still no work. I have-a backup copy of PGP software. I-a try to reinstall from that. ... Not again! Still nothing! But this same CD I-a use to install PGP on previous computer where-a everything work-a fine, and I-a using the same version of Windows!

Shall we put Luigi out of his misery and explain what’s gone wrong? Now when you double click on a PGP SDA the password entry screen pops up immediately—well, it pops up immediately apart from those computers on which it doesn’t pop-up immediately that is!

We had a theory that the reason for this delay is all down to the increase in processor speeds. If electrons are travelling at relativistic speeds close to the speed of light then they will experience time dilation effects. So, perhaps some whiz-kid in the PGP Corporation decided to add a time dilation calculation into the software. That would explain why a password screen that normally appears within half a second can take the order of 5 minutes to appear on some machines. We suggested this to the Prof, but, sadly, he wasn’t at all impressed with our theory. But he’s patient with us non-technical types, so he banged a few buttons on his calculator before announcing that “defects in the crystal lattice would certainly not allow electrons to travel at 99.83% of the speed of light”—hmm, ah, well, there goes our Nobel Prize! Let’s just call it a feature!

More realistically, it seems that the problem relates to the way different computers handle large executables. Given two computers running the same version of Windows, with the same amount of physical memory and swap file size, one may start executing the executable immediately, while the other first makes a copy. This would explain why the extent of the delay before the password window appears is proportional to the size of the SDA.

Now during the time that the SDA is communing with Einstein’s ghost the computer is frozen, giving the impression that it has crashed. Very few people are going to sit around for five minutes looking at a frozen screen on the off-chance that some kindly deity will step in and unfreeze it. Most people are going to reboot. And after a few equally unsuccessful attempts they are going to conclude that they have lost their much cherished data for good, and will soon be searching eBay for a voodoo doll with “PGP Corporation” stamped on the front!

Now since a PGP SDA is the only place where most users are likely to encounter multi-gigabyte executables it would be nice if the PGP Corporation forewarned a user in the documentation that the user’s “crashed” computer had not really crashed. We explained to Luigi that his SDA could still be used. There was a look of horror on his face for a moment as he tried to recollect whether he had wiped the “non-working” SDAs. Fortunately for Luigi—and we suspect for the PGP Corporation as well—he had not!

What goes in doesn’t always come out—easily!

So let’s join Luigi again as he waves his magic wand over his SDA for the second time.

I-a start the onsite SDA again. I-a note the time. ... One minute, nothing. ... Two minutes, nothing. ... Three minutes, nothing. ... Four minutes, nothing. ... Five minutes, nothing. Ha! Now-a the password screen appear. Ah! I-a waste so much time. These PGP Corporation people. Slime-a! Slime-a! Slime-a! Type in-a password and off-a we go. It’s-a big SDA so it-a take-a long time to decrypt, maybe half-a hour. So-a I do some work. Come-a back later.

Okay, let’s-a have a look. It-a should-a be done long ago. What’s-a this message, “Filename exceeds maximum length – try decrypting to the root of the volume.” Oh, no!

Now we all save web pages to our hard disks. And some of these web pages have rather long titles. And these rather long titles are used as the default file names. Now PGP will create an SDA using files with long file names without any difficulty—it doesn’t matter what directory the files are in. But when it comes to decrypting an SDA it’s a different matter. The SDA must be in the root directory of some partition if a filename exceeds a certain length. Otherwise, the poor user is forced to cancel, move the SDA, and start all over again.

Luigi’s response, “Why-a they-a not-a tell me this?” Why indeed! Given that it takes the order of 30 minutes to decrypt a large SDA, it’s not the sort of task Luigi—or even you dear reader—would wish to repeat too often! We explained to Luigi that product testing is not one of the PGP Corporation’s strong points.

Wouldn’t it be nice to have a little message during the encryption process telling the poor user that the SDA can only be decrypted from within a root directory? Wouldn’t it be nice if a little flag were set in the SDA so that the executable could inform the poor user that the directory in which he is attempting to decrypt the SDA is a “no-hoper” at the very beginning of the decryption process, and not 20 minutes later when the decryption process first encounters an “unsuitably” long file name? Of course we suffer from the strange conceit that software, even if it is not user friendly, should at the very least not be downright malicious, malevolent, and take a perverse pleasure in torturing its users—a conceit that’s clearly not shared by the PGP Corporation.

Size really matters!

Let’s rejoin Luigi and his ever increasing blood pressure!

Root directory. Start-a the SDA. Wait-a the five minutes while it’s-a communing with-a nature, or whatever it does. ... Now enter password. Now go away for-a long time while it-a maybe decrypt, or maybe not decrypt!

Ah! It’s-a done. Success! Four days! Four days to restore a backup of my data! Now let’s-a create a new PGP virtual disk. ... Okay, that’s done. Now let’s-a copy the backup files from the decrypted SDA to the virtual disk. Here-a we go. That little sheet of paper flying across from one-a folder to another. Who-a needs-a goldfish when he’s-a got-a Windows file copy?

Wow! It’s-a taking a long time with this file. Must-a be big. Maybe I leave it a little bit. A watched-a file-copy never-a finish!

Okay, I’ve-a had-a lunch and taken my blood pressure medication. Maybe I-a invoice PGP Corporation for my doctor’s bill. It’s-a been copying for over hour. Should-a be finished long, long time ago. No! No! No! It’s-a still copying the same file. Oh, no! It’s-a only a 50 Mb file. Should-a copy in a few seconds. I cancel. ... Now Windows it’s-a locked up! Try Ctrl-Alt-Del. It-a does bugger-all! Hard reset. ... Logon on. ... Nothing! Screen frozen. It-a look like PGP bugger up Windows operating system. I-a wait. ... One minute. ... Two minutes. Ah! It’s-a coming back! Message from Windows say it has reinstalled drivers and must restart. It seem this PGP it-a crap all over my registry. Reboot.

Now-a only one thing remain-a to do. Only one-a thing I need to do to-a be happy, to-a lower blood pressure. And this-a thing is to delete all software produced by PGP Corporation from my computer!

Shall we tell Luigi what’s gone wrong. Well, Luigi’s computer happens to use an SIS IDE driver. And...and...PGP virtual disk does not work on computers with SIS IDE drivers. Well to be fair it does work as long as your files are small. If you’re one of those strange people who wants to copy files larger than about 20 Mb—a music file, or, perish the thought, a PGP SDA file, for example—onto your virtual disk, then PGP will throw a tantrum and crash Windows (and if you backed up the PGP virtual disk file instead of first copying the contents to some other medium then...then you’re stuffed—though we’re sure you’d think of a more energetic expletive should it ever happen to you!).

If you’re lucky Windows will repair itself after the hard reboot. If not, then you’d better have a system image tucked away somewhere, or have a spare few days to hand so that you can reinstall Windows and all your software.

We explained to Luigi that product testing is not one of the PGP Corporation’s strong points—hmm! hmm! A glitch in the Matrix, or at least in that portion of it that passes for neural matter within the “Testing Division” of the PGP Corporation! They may not know how to test their software, but they’re certainly experts at testing their users’ patience!

For on-the-fly encryption Luigi is now very happily using TrueCrypt—its developers seem to have mastered the art of copying files greater than 20 Mb to a virtual disk! Luigi’s one question to us—in between gulping down his pills for high blood pressure—was, “How’s it-a possible for an organization as big as PGP Corporation to produce such a crap product?” Hmm! Difficult one that. If the PGP Corporation was a “one man and his dog” operation then all would be forgiven, but it’s not. It’s big, and its products are targeted squarely at the corporate sector, a sector that has a habit of getting a little testy when software doesn’t work straight out of the box.

It’s very difficult to envisage how a large corporation could have such a poor testing regime, one that allows the litany of sins, both of omission and commission, described above to get out the door. While no product is going to run on every custom-built box, well-tested products from major suppliers should at least run on the standard boxes produced by the main manufacturers. If you’re a company producing encrypted file system software, then you develop relationships with the developers of hard disk drivers, and you test them with your product while those drivers are still in beta, so that when a driver is released and used by the PC manufacturers you know that it will work with your product.

Much as we like the PGP Corporation, even in these post Zimmerman days, their report card must state, “Could do a great deal better!”

Tiffium & Morphium – Bigus Brutium-Absentium Zonium