Implementing a Pure Credit
Monetary System on the Internet

Abstract

This paper presents a new means for conducting electronic commerce, using a form of electronic cash. Unlike other schemes for electronic trading, this electronic cash can be reused like paper cash. There is no need to communicate with the banks during each transaction. This makes our system the only one which is truly cash-like. It works by using the underlying principles of a pure credit monetary system. The concept of double spending is used as a positive aspect of the system, allowing users to double spend notes, add value to notes, and split other peoples' notes into notes of smaller value. A platform-independent implementation has been completed in Java. The system exhibits the properties of transferability, scalability, security, and low transaction cost, and a degree of anonymity.

Introduction

While some Internet payment systems are simply glorified credit card payment schemes, others are payment clearance systems for traditional national currencies. This paper describes the design and implementation of a new scheme which in effect creates anbd regulates a new Internet currency which is decoupled from existing national currencies.

According to (Medvinsky and Neuman 1993, Okamoto 1992), an electronic currency should have the following ideal characteristics:

Transferability

The currency should be accepted by a wide range of entities: banks, merchants, and individuals. Ideally, a piece of currency may be passed between many parties without the need for validation by a bank.

Scalability

The currency system should handle a large number of users, and cope with increases in the volume of transactions. A system with a single, central server does not meet reasonable scalability requirements.

Security

Forging electronic currency should ideally be as difficult as or more difficult than forging paper currency. At the least, forgers should be caught.

Anonymity

An electronic currency should be as difficult to trace as a paper currency.

Cost

The cost of an individual transaction should be low.

Existing digital currency schemes

Credit-card based schemes

These are simply means for transmitting a credit card number securely from a customer to a merchant. The existing credit-card transaction clearing system is still used, and no new techniques are introduced. These systems include CyberCash by the Verifone company (CyberCash 1997), and the Secure Electronic Transactions (SET) protocol designed by Visa and Mastercard (Visa and Mastercard 1996). CyberCash uses a trusted third party to verify and process the transactions, whereas SET uses the concept of a Certification Authority to perform the clearing, and Acquirer Payment Gateways to interface between the Acquirer (bank) and merchant. Both systems simply add a layer of security to the transfer of credit-card information, by using third parties to clear the transactions. These systems lack transferability (only registered merchants and banks can accept credit cards), anonymity (credit-cards are inherently traceable) and cost-effectiveness (the individual transaction cost is relatively high).

EFTPOS systems

Electronic Funds Transfer at Point of Sale uses a debit card and secret identification number to transfer money directly between bank accounts, without any physical medium being transferred. Such account-transfer systems can easily be implemented on the Internet, by requiring the user to maintain a connection with his or her bank whenever a transaction is to take place. Example systems include Carnegie-Mellon University's NetBill (NetBill 1997) and the First Virtual Bank (First Virtual 1997). These systems require the user, merchant and bank to be connected at the time of the transaction, although First Virtual delays the transaction somewhat by using MIME-encoded email messages (Borenstein and Freed 1993) to perform the transactions. The need for a connection to the host bank introduces scalability problems: for example, when many people want to use the bank simultaneously, the system may become overloaded.

Electronic Cheque systems

These could also be described as "delayed EFTPOS systems" because they are based upon account transfers. These systems feature single-use tokens to represent money from the account, analogously to paper cheques. Such systems have varying degrees of anonymity and scalability. NetCheque (Medvinsky and Neuman 1993) is overtly a cheque-based system, but NetCash (Medvinsky and Neuman 1993) and DigiCash's ecash (Chaum et al 1985, DigiCash 1995), invented and patented by David Chaum, purport to be cash, even though they do not work like cash with respect to the reusability of their tokens. In effect, these tokens need to be re-validated by a bank as each transaction takes place. DigiCash claims that its system is cash-like because it can be untraceable, but it has scalability problems due to the fact that to disallow users from spending the same money twice, the serial numbers of all notes must be stored at the central bank. NetCash addresses this problem by introducing the concept of currency servers, which handle the coins for a particular group of e-cash users. NetCash has scalability advantages, and ecash has guaranteed anonymity, but both are single-use tokens, equivalent to a cheque.

Evaluating the above systems according to the five characteristics described above, we see that transferability in its true form is not supported by any of the systems. None of them allow a note to pass from user to user without the bank's intervention. Scalability is achieved in NetCash through its use of currency servers. The other systems described do not rate highly with respect to scalability. Security is the main characteristic without which no electronic currency system could work, so all systems support this. Payee anonymity is guaranteed in Chaum's ecash only. Other systems offer a level of anonymity as an added feature. The cost of transactions is high in all systems considering the large workload put on the bank, but it is especially high in credit-card systems.

In this paper, we introduce a new scheme which, we argue, meets Medvinsky and Neuman's characteristics better than any of the systems mentioned above. It has the unique characteristic of true transferability; that is, a piece of currency can be passed on between many parties before it is deposited at the bank. This is achieved by using the special properties of a pure credit monetary system. It also achieves scalability, security, low-cost, and a reasonable level of anonymity as an added feature.

All of the above systems, and indeed all electronic commerce systems proposed in the literature, are assumed to be tied to a national currency: US dollars, British pounds or another system. Thesee systems tend to make the Internet economy somewhat dependent on the fickleness of national currencies. We suggest that the Internet could have its own currency, which transcends national borders and escapes the economic control of individual governments. We claim that "starting from scratch", as it were, with the Internet economy, can avoid some of the stability problems inherent in current monetary systems.

The Loans Standard monetary system

To avoid inflation caused by customers defaulting on their debts, an interest margin is introduced to the system. Customers with outstanding debts are charged interest, which possibly varies according to the risk of the loan, while customers with positive bank balances are paid interest. The margin between these two interest rates accounts for bank transaction costs and bad debts. It is up to the bank to try to prevent defaults and to take action to reclaim money lost in defaults, in order to minimise the amount of the interest rate margin which is wasted in compensating for bad debts.

This system has several benefits over monetary systems currently in use. Trade is not artificially restricted by the amount of money in circulation, because money is created as it is needed. Furthermore, it avoids "bank runs", where customers try to reclaim their money from an insolvent bank. This is due to the fact that the sum of money in circulation is always equal to the sum of money loaned by the bank, as opposed to a reserve system where the bank only holds a percentage of its deposits. In effect, the value of money is guaranteed by the system, not by the individual banks.

It has been suggested that the Loans Standard monetary system would provide an excellent basis for an Internet commerce system (Goldschlager and Harper 1996). We have developed a prototype implementation on the Internet, partly to determine if this claim is true in terms of monetary stability, and partly to test the feasibility of the requisite software components of this type of electronic monetary system. The implementation is in the form of a set of platform independent Java components which plug in to standard Internet software components such as Web browsers and email programs.

A true electronic cash system

The transferability property is an important one, but no current Internet currency system can implement it due to what is known as the double spending problem: all units of currency are represented electronically as some type of serial number, but of course any digital note is trivial to copy (quite independent of encryption schemes) so the bank must ensure that a note has not been spent twice. For all existing electronic money proposals, this insurance involves communicating with the originating bank at the time of transaction to check that the note has not been spent before. This creates problems of scalability and transferability.

The Loans Standard system, which allows users to go into debt, can actually allow double spending to occur legitimately, so the constant communication with the bank is unnecessary. A system of certificates, similar to cheque guarantee cards, can be used to ensure that users do not enter into too much debt. The LS system relies on the ability of the banks to redeem debts from their users, and on the interest margin between the level paid to people holding money and that collected from debtors, to cover bad debts.

Certificates

The certificate is used as a guarantee of creditworthiness, similar to a cheque guarantee card. The bank customer presents the certificate with his or her note, and the recipient verifies the transaction according to the following algorithm:

1. Consult "Bank ID" part of certificate: if I don't have this
bank's
current public key in my cache, obtain it from my own bank or the local public
key registry.
2. Use the bank's public key to verify the signature on the
certificate; if the certificate doesn't match, reject the transaction.
3. Check that the user ID and email address contained in the certificate match
those in the accompanying note. If not, reject the transaction.
4. Accept the certificate.

Notes

BANK-ID: CBA-1234
VALUE: e$20 alice bob #001 20/7/97 <sig>
BANK-INFO: {e$20 alice bob #001 20/7/97 <sig>}
		(encrypted by CBA-1234's public key) CBA-1234
SIGNATURE: <signature of the lines above>

The BANK-ID line specifies the unique identifier of Alice's bank. The VALUE line contains several pieces of information about this transaction. Firstly the value of the note at this transaction is stored, then the unique IDs of the current payer and payee, in this case Alice and Bob. The serial number of the transaction between these two parties is also stored, so that separate transactions between these two parties can be distinguished from each other. Next is stored an expiry date, before which this note must be deposited or used. Then this line is signed by the payer, to certify that the information has not been tampered since it left Alice's computer.

The BANK-INFO field contains an exact copy of the VALUE line that has been encrypted with Alice's bank's public encryption key, and Alice's bank's key ID. The usefulness of this becomes apparent when the note is passed on. Finally, Alice signs the entire note

Alice sends this note, along with her bank certificate, to Bob, who processes the transaction as follows:

1. Check certificate according to above algorithm.
2. Take Alice's public key from her certificate, use it to check the
signature of the note. If signature doesn't match, reject the note.
3. Confirm ID strings of Alice and myself in VALUE section of note. Check
expiry date.
4. Confirm that we haven't received this note from Alice before (check serial
number in VALUE). If so, reject note.
5. Check that BANK-INFO line is truly the encrypted form of the VALUE line. If
not, reject the note.
6. Compare transaction value with Alice's transaction limit encoded in her
certificate: if transaction > limit, make a direct connection with our bank
(who will in turn connect with Alice's bank). Send the user ID and value to the
bank for clearing. If credit check is denied by the bank, reject the
transaction.
7. Accept the transaction. Keep the note for later deposit or spending. Send
receipt to Alice.

The serial number in the VALUE section of the note is used to keep track of the note when double spending occurs. If a note with the same serial number is seen twice by the bank, it knows to withdraw extra money from the account of the receiver of the double spent note. This puts the onus on the receiver of a note to make sure that they haven't received the note before. This distributed authenticity check makes the system more secure and takes some of the load from the banks.

The transaction limit system provides security from fraud by forcing spenders to stay below a certain limit for non-authorised transactions, similar to a credit card floor limit. This will discourage fraud, as it becomes very difficult to defraud enough money to make the risk of fraud worthwhile. This topic is covered in greater depth in the next section.

The usefulness of the BANK-INFO line becomes apparent when we see that the note can be passed on to another user in the system. Let us say that Bob, who banks with ANZ-5678, sends his newly received note on to Carol as follows:

BANK-ID: ANZ-5678
OLD-INFO1: {e$20 alice bob #001 20/7/97 <Alice's sig>}
         (encrypted by CBA-1234's public key) CBA-1234
VALUE: e$20 bob carol #023 20/7/97 <Bob's old-info sig> <Bob's sig>
BANK-INFO:{e$20 bob carol #023 20/7/97 <old-info sig><sig>}
		(encrypted by ANZ-5678's public key) ANZ-5678
SIGNATURE: <signature of note> 

Note that Alice's VALUE line is not included;. it only appears in encrypted form as OLD-INFO. This provides an amount of anonymity, whereby Carol can't learn that Bob received the note from Alice.

Another addition is the <old-info-sig> in the VALUE line. This is Bob's signature of Alice's BANK-INFO line, which is a way of proving that Bob has checked the VALUE against the BANK-INFO and verified its correctness. Each person who handles the note creates a new OLD-INFO line to add to the note using the previous BANK-INFO line. The OLD-INFO lines are numbered sequentially. The bank uses the OLD-INFO lines to check for double spending and malicious damage. This is described in more detail in the next section.

Detecting fraud, malicious damage, and double spending

A similar process takes place for double spending: when a note is presented twice, the banks go through the OLD-INFO lines, determining who spent the note twice, and the extra money is charged to their account.

This means that we are using the "problem" of double spending in a positive way. There is nothing to stop a user "adding value" to a note, or spending the same note twice: the user simply has the extra money drawn from their bank account (or, equivalently, added to their Loans Standard loan). A user can also "split" a note into several notes of smaller value, double spending or depositing as necessary to obtain the full value for the original note. We entirely avoid the problems inherent in double spending recovery procedures noted in (Okamoto 1992, Pfitzmann et al 1995) by simply allowing double spending to happen legitimately, with well-defined consequences.

Redeeming value from a note

So, in the majority of cases, a note can be passed from person to person with the transaction cost limited to the communication between the two parties. This allows the transaction cost to be much smaller than that of other schemes in which the payer's bank must be contacted for each transaction to validate that transaction.

Anonymity and scalability

Using this system, the only communication that a user needs to have with a bank is to deposit notes, or to verify transactions which are over a user's assigned transaction limit. The banks will need to intercommunicate to redeem the value of any note which is finally deposited, but only from the originator's bank to the depositor's bank in the usual case. In general, there is no need for any communication with the banks of any of the intermediate people who passed the note along. Intermediate banks will only need to be contacted when a user double spends. This enables much better scalability and cost than current systems.

An impractical, but theoretically interesting property of this system is that if the transaction date were added to the note, then banks could pay and claim interest while the notes are actually in circulation. Theoretically this is possible, but in practice it would involve a large amount of computation and cooperation by every bank whose customers handle a note, thus removing some of the low transaction cost benefits of the system.

The prototype implementation

One way this was achieved was through the use of email. Simple Mail Transfer Protocol (SMTP) is a simple store-and-forward messaging mechanism which does not require users to be connected to the Internet at all times. Our monetary transactions are encoded using a special MIME type (Borenstein and Freed 1993), which allows content handlers to be used to process the incoming messages. A standalone program is used to send money, handle the user's bank account, and request money from other users. An advantage of using a MIME type is that a Java content-handler or Netscape plugin can be used to process transactions on the World Wide Web. Thus money can be transferred via Web pages or via email according to what is convenient for the user.

The standalone program allows users to spend money, and maintain their bank accounts. This involves depositing notes which are approaching their expiry date and small notes which are otherwise useless. This can be done automatically. Users can also check their bank balances, and apply for increased loans.

The mail handler receives incoming requests for money, prompting the user for payment when necessary. It also receives incoming payments, and adds them to the user's "money bag".

The transactions used in the implemented system deal with system maintenance, account application and information, actual payment, and key transfer. We divide the transactions into three main types, plus an error transaction.

1. Account maintenance

REQUEST-ACCOUNT	Request a new bank account
REQUEST-LOAN	Apply for a loan increase from the bank
REQUEST-BALANCE	Request account balance information
BALANCE-INFO	Send account balance information
CERTIFICATE	Send a party's certificate

2. Using the bank

REQUEST-KEY	Request a party's public key
KEY	Send a party's public key
DEPOSIT	Deposit money in the bank
WITHDRAW	Get guaranteed money from the bank

3. Spending / receiving money

REQUEST-PAYMENT	Request money from a party
PAYMENT	Send money to a party
RECEIPT	Send a receipt

Some of the transactions require a certificate to be transmitted along with the transaction information, and many of the transactions would benefit from having an accompanying message in plain English, so we use multipart MIME messages to transmit the transactions. This system is based upon the application/green-commerce model (Borenstein and Rose 1995), introduced for the First Virtual credit-card banking system.

For example, a loan request message would look similar to the following:

From: Joe Bloggs <joebloggs@myorg.com.au>
To: The Left Bank <leftbank@rive-gauche.com.au>
Mime-Version: 1.0
Content-type: multipart/mixed; boundary=ls42
Subject: Request for Loan Increase

--ls42
Content-type: application/loans-standard; 
		transaction=request-loan

USER-ID: joebloggs@myorg.com.au
LOAN-LIMIT: 1000.00
TRANSACTION-LIMIT: 500.00
SIGNATURE: <joebloggs' signature of the above>

--ls42
Content-type: application/loans-standard;
		transaction=certificate

BANK-ID: leftbank@rive-gauche.com.au
USER-ID: joebloggs@myorg.com.au
USER-EMAIL: joebloggs@myorg.com.au
EXPIRY-DATE: 28 Nov 1997
TRANSACTION-LIMIT: 100.00
PUBLIC-KEY: <joebloggs' public key>
SIGNATURE: <LEFTBANK-001's signature of the above>

--ls42--

The other transaction messages are analogous.

Using email to transport the messages allows us to send peer-to-peer payments, as we are not relying on the receiver to be online at all times. Systems which require online clearing usually require both users to be online at the time of the transaction, but this is not necessary in our system.

The application suite was written in the Java language, for maximum portability and integration with the World Wide Web.

Client application

The client program receives a command to "send e$X to user Y", and works out the best way to do this: to send notes from its money bag, split notes in the money bag, create a new note, or withdraw a note from the bank. The heuristics used to achyioeve this look at the the notes currently held in the money bag, and the user's transaction limit and bank balance.

Mail handler

Upon receiving a request, the mail handler reacts appropriately: it asks the user for confirmation before honouring a payment request, or it adds a new note to the money bag, or update's the user's information.

Bank server

Meeting the criteria

A way to achieve this in a transitional system might be for each user to present a credit card account as the guarantee for their Internet payment account. If the bank wants to redeem the user's debt then it can simply convert the debt to the local currency and withdraw the amount from the user's credit card. Residual user defaults are absorbed by the interest margin.

Another variation is to give out certificates with a zero dollar transaction limit, so that every transaction must be verified by the bank and the user cannot enter into credit. This allows people with no financial credibility to also participate in the Internet payment system. However, these individuals are only able to pass along electronic notes which they have previously earned. A zero transaction limit will cause an added value or double spent note to be rejected by the bank as it is used if the payer doesn't have sufficient funds in the bank. The payer cannot draw against a credit limit.

Conclusion

A prototype of the system has been successfully implemented using platform independent software components which can plug in to MIME compliant email programs and Web browsers.

Acknowledgements

Bibliography

N Borenstein and M Rose (1995) The application/green-commerce MIME content type, First Virtual Holdings Limited, 1995. URL: http://www.fv.com/pubdocs/agc-spec.txt

D Chaum (1985) "Security without identification: Transaction systems to make big brother obsolete", in Communications of the ACM, 18(10).

D Chaum, A Fiat and M Naor (1988) "Untraceable electronic cash", in Proceedings of CRYPTO '88, Springer-Verlag, Berlin.

CyberCash (1997) CyberCash Home Page at URL: http://www.imla.com/cyber.html

DigiCash (1997) DigiCash Home Page at URL: http://www.digicash.com/digicash/company.html

First Virtual (1997) First Virtual Home Page at URL: http://www.fv.com/info/index.html

LM Goldschlager (1991) What is Money? Technical Report 91/152, Monash University Computer Science Dept.

LM Goldschlager and R Baxter (1993) The Loans Standard Model of Credit Money, Technical Report 93/183, Monash CS Dept. Also in Journal of Post-Keynesian Economics, Vol. 16 no. 3, 1994.

LM Goldschlager and IR Harper (1996), "A Proposal for a New Monetary System to Support Financial Transactions on the Internet", in Proceedings of the First Australian Computer Money Day (CMD '96), Newcastle, March 1996.

G Medvinsky and BC Neuman (1993), "NetCash: A design for practical electronic currency on the Internet", in Proceedings of the First ACM Conference on Computer and Communications Security

NetBill (1997) NetBill Home Page at URL: http://www.ini.cmu.edu/NETBILL/

T Okamoto and K Ohta (1992), "Universal Electronic Cash", in Proceedings of CRYPTO '91, Springer-Verlag, Berlin.

B Pfitzmann, M Schunter and M Waidner (1995), "How to Break Another 'Provably Secure' Payment System", in Proceedings of EUROCRYPT '95, Springer-Verlag, Berlin.

Visa and Mastercard (1996), Secure Electronic Transactions: Technical Specifications, URL: http://www.mastercard.com/set/set.htm

Copyright

[All Papers and Posters]