In designing our protocols, we made a variety of assumptions about the capabilities of the participants and made use of several cryptographic tools. This section describes our assumptions and introduces some of the important tools which will be used.
Four parties participate in our protocol: a consumer C, a merchant M, a bank B, and a transaction log L. Now, of course, our parties are designed to allow multiple, scalable, simultaneous transactions that do not interfere with each other -- this is the isolation requirement in ACID transactions. Thus, there can be many more than four parties -- but in a single transaction, there will only be four parties.
All parties can perform basic cryptographic operations, e.g. cryptographic hash computation, signature computation and verification. All parties have well-known or verifiable public keys. All signatures can be verified by the receiving party.
To justify the claim of anonymity, the identity of the consumer must be protected from all other parties (that is, we make assumptions of strong anonymity).
We assume that the communications channels (in particular those between the consumer and the other parties) are anonymous, i.e. no information about the identity of the consumer is gained by communicating with the consumer. Now, in practice, this may be a questionable assumption -- can't a merchant or a third party infer the consumer's identity through the TCP/IP return address on his packets? Supporting this assumption in an implementation may involve a fifth party, an anonymizer, which the consumer trusts not to reveal identity information.[8]
To provide atomicity, a modified, cryptographic version of the two-phase commit protocol is implemented using an external, publicly accessible transaction log. The transaction log receives and records messages, and then reproduces the recorded messages. The log localizes the global commit decision to a single entity. The log also acts as a time-keeper, determining when to abort transactions due to a time-out.
Communication channels are assumed to be secure. The method used to implement this security (e.g. public keys) is not important to the functioning of the protocol. Some messages could be left unsecured, improving efficiency at the cost of a limited loss of privacy, but the details of this are not currently addressed.
Chaum [6] made a critical discovery that enabled the
idea of digital cash to take place: blinded tokens.
The use of blinded tokens is essential to our protocols. A token is a
piece of data which can be created only by a specific issuer.
Creation of a token without assistance from the issuer should be
computationally infeasible. Blinded tokens are created by an
interaction of a consumer with the issuer (the bank). After the
interaction, the consumer has knowledge of a token which the issuer
can not specifically identify. That is, the issuer does not know
which token (from the range of valid tokens) the consumer has
obtained. The tokens used in this protocol will have the additional
property that each token, denoted 
, specifies the public half
(including modulus), denoted Q, of a public key pair.
It is assumed that the consumer has an account with the bank, and that the bank can mint blinded token currency. This requires the bank to maintain token information as detailed in Section 5.
The transaction protocol given assumes minimal preparation and delivery costs for the goods. Goods must be prepared and delivered, although not in a usable form, prior to any guarantee of payment to the merchant.
Message signatures are computed on hash values of the plaintext, and
then appended to the plaintext to form a signed message. This is
relevant in the first step of the purchase protocol, 1, for
efficiency reasons. It is also relevant in the second step,
2, so that the bank can read in order to determine
Q. This assumption can be dropped with minor changes to these steps.