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!
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):
- 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!