Towards anonymous currency transactions

Automated disclaimer: This post was written more than 16 years ago and I may not have looked at it since.

Older posts may not align with who I am today and how I would think or write, and may have been written in reaction to a cultural context that no longer applies. Some of my high school or college posts are just embarrassing. However, I have left them public because I believe in keeping old web pages aliveā€”and it's interesting to see how I've changed.

Anyone can create and maintain an anonymous online identity through the use of Tor and carefully chosen browser settings, but a difficulty soon arises: How does one pay anonymously for services? Some hosting and email providers accept digital currency (usually e-gold), but the process of getting e-gold in the first place is a bit trickier. Every reputable-looking digital currency exchange service that I've seen demands some proof of identity in a bid to prevent money launderers and financial fraudsters from using their system. There used to be a service that allowed anonymous digital currency transfers (YodelBank), but it closed when the operator became weary of running it. Where does this leave anonymity-seekers? I have a proposal for a system that could allow (though not guarantee) anonymous, blind transfers without opening avenues for money laundering.

Kinda like traveller's checks

The idea really isn't that revolutionary, and is probably best illustrated by example. Let's say Alice wants to send 5 grams of gold anonymously to Bob. Alice goes to the Mixer service and spends 5 grams of e-gold. The Mixer receives the gold into its own account, creates a database entry with a 512-bit code, and returns a Certificate to Alice. The Certificate is a text file (signed by Mixer) that contains the database entry's ID and code and a statement that it was issued for 5 grams of digital gold. Alice sends an encrypted copy of this to Bob. Bob decrypts the Certificate and "spends" it at the Mixer, which destroys the Certificate's database entry and transfers roughly 5 e-gold from Mixer's account to Bob's account. (Why not exactly 5 grams? See the section on fees.)

Caps and limits

Caps and limits prevent the system from being useful for money laundering:

  • To create an account, the user must have a working email address and a 2048-bit (or larger) PGP key with that email address as one of the user IDs. No two accounts may have the same email address (or PGP key). This should limit the number of accounts that can be created.
  • Certificates are capped at a quantity equivalent (at purchase time) to US$50.
  • A user may only purchase or spend 4 Certificates or US$200-equivalent per month, whichever comes first.

Further details

Protecting the Mixer

To protect the administrator of the Mixer, the service could be run as a Tor hidden service, preventing intrusion or interference by the authorities. This also makes sense because users should be using Tor in the first place.


Maintaining an e-gold account incurs monthly service fees (currently 1% per annum), and each transfer incurs a fee as well. Since the Mixer maintains a pool of e-gold representing the sum of all issued Certificates, at some point it may be unable to redeem a Certificate due to account maintenance fees. To prevent this, each certificate may be redeemed not for the amount originally purchased, but for the amount remaining after fees. In other words, the Mixer maintains strictly segmented accounting. Obviously, the longer a Certificate is held, the less it can be redeemed for.

Threats to anonymity

Each transaction is visible to e-gold, who could conceivably link two transactions that are close in timing and amount. Holding a Certificate for a longer period of time could allow for a better mixing effect.

Data security

The server's private key would be kept only in system memory, and the disk's empty space would be periodically shredded (the usual measures.) Several offsite boxes could be maintained, to which the main Mixer would send encrypted backups to be stored in rotation.


I'd prefer to implement the Mixer on a standard LAMP box, running a Tor hidden service but not an exit node (to minimize chances of service interruption.) The source code would need to be developed under the GPL by a team of security- and anonymity-conscious coders.

I plan on developing a working proof-of-concept model of this for my senior I.S., pending approval by my advisor. So, what do you think?

Responses: 8 so far Feed icon

  1. Mark Herpel says:

    very interesting and I would like to hear more, please update me to your progress. I created three years ago to list online payment systems so I've seen many come and go. There is a similar system to this you discuss above called LOOMGOLD [extra URLs removed]

    The programmer who created it is very good contact me anytime I'd like to hear your progress Mark

  2. Tim McCormack says:

    You know, I think I like that system more than mine. (It creates a larger mix without incurring e-gold Spend fees.) All the nodes are still under the control of one entity, but that's going to be hard to eliminate without true trust-based financial networks.

    I don't see how one would get e-gold (or another widely accepted digital currency) into and out of Loom. The main exchange server listed,, appears to be gone.

  3. Mark Herpel says:

    TOR also has back doors and problems, RE:

    True the Loom system requires exchange agents, (or a prepaid card system for funding and withdrawals, I have that one already up for e-gold)

    I know all of those agents listed and the they change often however, Loom is not today a really active system its put up as the first completed working version beyond anything resembling a beta because it works well. I think it is just kind of in limbo now while he works on other paying projects, but not sure.

    Also don't miss the fact that the valued object or 'money' loom users can exchange, does not have to be e-gold, you can set up your own Loom for Pecunix, silver coins, antique plates, '56 Buicks or Star Trek Merchandise.....anything you and the receiver agree on. Its a bit generic that way as I understand it but that is how it was created.

    There are several other systems, open source, I have them on another laptop listed in details, Loom is the only one I know the actual programmer and trust his work and him 100%.

    Don't forget, most people wanting to 'anon' transfer funds are looking to do much more than a few hundred dollars.

    All the best. Mark

  4. Tim McCormack says:

    I'm surprised that Loom is completely fee-free -- there should be some sort of basic maintenance fee that reflects the "backing store's" maintenance costs. That is, suppose Loom is just one big e-gold account with an innovative front-end. Then, the amount of gold available for withdrawal from or transfer between locations after X days should reflect the 1% per annum Agio fee of e-gold. (The Spend fee would be more easily calculated.) Otherwise, Loom risks insolvency.

  5. Mark Herpel says:

  6. rlruby says:

    can you guys make a program for such a thing. like TOR did. but also, make versatility options, make them know how to use egold, paypal, and i think there is a third one.

  7. Tim McCormack says:

    It would be neat to have an application manage all this for you, but you'd have to be very careful -- imagine I create this application, but put in a backdoor so I can spy on your transactions and skim off money? You would likely never know.

    In other words, when dealing with anonymity and security, keep the number of people you blindly trust to a minimum.

  8. Soi Disant says:

    I'm not one to need transferring large sums, nor make large anonymous purchases, but it seems that the monetary limit for service of this kind would need to be greater than US$200. I'd suggest US$500. And (if/as) hyperinflation hits the US, that would not even begin to be useful.

Self-service commenting is not yet reimplemented after the Wordpress migration, sorry! For now, you can respond by email; please indicate whether you're OK with having your response posted publicly (and if so, under what name).