There are many good reasons to have some degree of anonymity: people want to avoid being added to mailing lists, or simply keep secret the kinds of goods they buy; businesses may not want competitors to know what kinds of information they are buying. The strongest form of anonymity (unconditional) is provided by systems based on so-called blind signatures [10]. (These systems were first proposed by Chaum [8]. At this point, there are many of them published.) However, these systems have many well-known drawbacks. Tygar and Yee (as reported in [22]) point out that the protocols lack atomicity: network failures during a transaction will result in loss of the electronic money involved. That double spending is only caught after the fact is considered too high risk by banks. Another problem (as pointed out in [16]) is scalability: as all coins that have been spent have to be recorded, the coin data base will grow over time, increasing the cost to detect double spending. Attempts to address some of these issues have been made (e.g. via escrow [13]) and stored-value card based settings mitigate others [7], but drawbacks remain.
Mondex [14], on the other side of the spectrum, provides no anonymity. It seems to be a shared key based card design. There are well-known scalability and security problems with such designs. For example the security is totally dependent on the security of a master key, and this master key must be distributed to many users and points of sale across the system. If a single module is penetrated, not only is significant retailer fraud facilitated, but the entire card base may be compromised.
NetBill [19] has a large spectrum of desirable properties, including atomicity. It might be able to provide some limited anonymity via trust in the NetBill server and the use of pseudonyms, but linkage is still possible. Also the NetBill server maintains accounts for buyers and merchants, which is costly. Also, NetBill's transaction protocols include functions that are beyond payment, such as price negotiation. The trend nowadays is that these functions should be separated, and standardized; e.g., JEPI [12], SEMPER [20].
Our design (its network version) shares many features with NetCash [16,15] (NetCash has no ``off-line'' operation, meaning the ability to also work with stored-value cards). The NetCash protocols also combine symmetric-key cryptography for performance with public-key mechanisms. A consequence of shared-key operations is no non-repudiability in some key functions (e.g., in exchanges with currency server). Anonymity in NetCash is also trust-based, with multiple currency servers which the client selects; this in turn implies an accounting infrastructure in order to maintain consistency accross servers, etc. [17]. Additionally, NetCash is cast as a framework that can accommodate various electronic currency mechanisms,
iKP [3], SET [21], etc., are credit card-based payment systems. We are looking for some form of cash.