This article describes the DMT's
anonymous account system. There are four parts to the explanation. The first part is a
simple description of the set of activities that are involved in various DMT transactions—
such as placing assets into DMT, transferring value between accounts, and removing
money from the system. The second part is a precise mathematical description of the
protocols followed in effecting these transactions. The third part is a detailed numerical
example illustrating one of these protocols. The final part is a concluding discussion of
the merits and limitations of the system.
The anonymous account system is essentially a set of protocols--a set of procedures
which maintain anonymity and security--and that is what is described here. Those who have
difficulty following the mathematics (in the sections labeled "Part 2", below)
may want to skip forward to the numerical example, before looking at the math behind
the system. (For an introduction to the mathematics involved, see the author's "Cryptography and Number Theory for Digital Cash".)
We began at the point a customer has downloaded a copy of the User Module and
installed it on his machine. The module--written in Java--will operate cross-platform: in
a Microsoft Windows, Macintosh, or Linux environment. The module may be
downloaded free of charge by the potential customer, since DMT does not want to create
barriers to entry into its banking system
Part 1: Preliminary Considerations
The design criterion followed here is KISS: keep it simple, stupid. Software systems go
awry because it becomes increasingly easy to make implementation mistakes the more
complicated the underlying system. There should be nothing present in the underlying
system not necessary to accomplish its goals. And the principal goals--anonymity and
security--should be kept clearly in mind at all times.
A survey of digital cash systems planned or being implemented in the real world shows
that there is misplaced emphasis in preserving the anonymity of the spending of
individual coins ($100 coins, say). But there is no attention whatsoever paid to the
anonymity of the account from which they are withdrawn, or to which they are deposited.
In short, all existing systems that we have surveyed miss the point, if the point is defined
as the creation of a system that allows the anonymous holdings of assets.
In order to understand the anonymous account system, it is helpful to approach the
system synthetically. First, we look at the minimal numerical information that must be
present in order for the DMT to carry out its essential activities. Next, we outline the
specific actions where those numbers are used. Then, in the sections following, we fill in
some mathematical details, and point out how this system meets the necessary privacy
Part 1: Minimal Numerical Information Requirements
1. For a customer deposit into the DMT system, there must be present
2. For the DMT customer data base (each currency kept separately), there must be stored
3. For enacting a transfer within the DMT system, there must be revealed
4. For withdrawal out of the DMT system, there must be revealed
Considerable thought indicates that the system cannot be reduced smaller than this.
However, the numbers mentioned here do not themselves constitute a system. Rather,
they acquire significance once we explain their use in a specific context , and show the
procedure for their generation and transfer.
Part 1: Activities Associated with the Minimal Numerical Information
The next step is to outline the activities associated which these various numbers. Here we
supply a bare minimum of detail, because the listed actions are capable of being
implemented in a variety of different ways. Only afterward, in the following sections, do
we specify precisely how we propose to enact the protocols.
1. To initiate a customer deposit into the DMT system
2. For the DMT customer data base (each currency kept separately)
3. For enacting a transfer within the DMT system
4. For withdrawal
We now proceed to give a mathematical description of these activities.
Part 2: Making an Anonymous Deposit into DMT
Opening an account at DMT is as simple as depositing money into an account. There is
no separate account opening protocol, but only a deposit protocol. Customers are
anonymous, so DMT needs no customer information. The account number is generated
by the customer, and stored by DMT along with a record of the deposit. Here are the
mathematical details (bit lengths are for illustration):
Notice that at this point DMT has no idea who the owner of the deposit is. Even if the
transfer to the overt account is identifiable, there is no way to know if the customer
claiming the account is the same person.
Notice further that the customer who claims the account contacts DMT without revealing
the customer's own identity. This contact can be done conveniently through the User
Module, but also through anonymous email, or a nym server. (To be sure, the challenge-
response may be laborious in the latter two cases. However, the User Module may be
used to produce the relevant numbers and export them in ASCII format, in a manner
similar to PGP.)
It is up to be customer to take ordinary privacy precautions with respect to the email
address used. The Digital Monetary Trust will not be recording a customer's Internet
activities, but others may be. This process is analogous to a "walk-in" customer at an
Austrian bank who requests an anonymous passbook account. Even though the bank may
not ask for customer identification, there is no assurance that someone is not across the
street taking videos of entrances and exits, and attempting to match pictures with names.
In addition, to the extent banking regulations permit, the original transfer could be
anonymous. It could be a payment in anonymous ecash coins, for example. (At least that is
an eventual goal. Digital cash purveyors have done little to get their systems off the
ground.) Another approach is to take advantage of the sheer cost of information,and to receive consulting or
other payments as transfers to the DMT system. Such payments are in principle traceable
up to the point of deposit, but at high cost to the researcher. However, since the origin
of the funds is clearly legal, there is a high-cost burden-of-proof on any agency that wants
to make an issue over the deposit.
Note also that outside transfers into existing accounts are not allowed. For in that
case, the initial identifying number H(y) could be the same as the identifying number of a
previous outside transfer into the system. This would make cheap correlations possible
for someone monitoring wire transfers to a DMT trustee.
Part 2: Account Storage in the DMT Database
Each currency is stored separately in the customer data base. The DMT has a separate
public signing key gk (where k is one of the DMT's private keys) for each currency
denomination. The DMT stores the 160-bit account number y, the amount C (a 32-bit
number), and also a 32-bit random nonce. In addition, c* is stored as an index (record
locator). The latter is important, because the rest of the record will be encrypted, but c*
can be located by a simple comparison. If each record had to be individually decrypted as
part of the search process, then the database search time might take too long, once the
database becomes large.
Notice that, in the absence of decryption, the only thing stored in the DMT database that
correlates with any number stored in a customer's browser is c* = H(C||y||A*). Seizure
of the database would supply no information about customer accounts, unless the
customer account information C, y, A* were already known (so that the hash of the
concatenation could be calculated), in which case the seizure of the DMT database is
irrelevant. Even so, seizure of customer records stored with the customer's browser
would not allow one to make a withdrawal, without knowledge of the customer's private
key also. (The private key will be stored in encrypted form, and accessed with a pass
phrase in a manner similar to a private PGP key.)
Each time the computer stores an account record, two backup copies are made at
remote locations. With respect to the two backup servers, the DMT primary server
generates symmetric encryptions keys and encrypts the record information with the
public keys of the backup servers. The actions with respect to the backup servers take
place as follows:
Part 2: Transfers Between Anonymous DMT Accounts
When a customer ("paying" customer) desires to make a transfer to another DMT customer
("receiving" customer), the paying customer first requests an identification number from the
Note that, as an alternative to generating a new account number y*, the receiving
customer could simply supply H(z) to the paying customer, where z is an existing
account number. If observed, however, this use of H(z) could potentially be linked with
previous or subsequent uses of H(z). Nevertheless, internal transfers into existing
accounts will be allowed, as opposed to outside transfers into the DMT system.
Recall that this deposit, or transfer, may be made to an existing account or to a new
account. We will here assume the receiving customer deposits to a new account.
Note that the DMT (which is not looking in the first place) has no idea to whom the
transfer has been made. The paying and receiving customers may, in fact, be the same
person. But there is no way to know this.
Part 2: Transfers Out of the DMT
For withdrawals out of the DMT system, the owner of the account from which the
transfer is made must supply the trustee of the DMT overt account with a claim number.
The same claim number, as well as a pre-image, must be supplied to the person who receives
the transfer. If the person receiving the transfer ("beneficiary") is a DMT customer (or
has the DMT software), the beneficiary can generate his own claim number and pre-image.
The steps are those following.
When a customer (paying customer) desires to make a transfer to a beneficiary outside
the DMT system, the paying customer first requests an identification number from the
beneficiary, or else creates these number himself and forwards them to the beneficiary.