Now What?

Here’s what I’ve got planned for AEIOU now:

OpenPGP Integration

An issuer in the AEIOU system is currently identified by their username and the domain name of their server.  This is less than ideal.  If a server has multiple domain names (perhaps it runs as both a Tor hidden service and an I2P eepsite simultaneously), users won’t automatically know that a given username is equivalent across domains.  Worse, if someone hijacks or otherwise acquires a server’s domain name, they’ll be able to impersonate all of the issuers on that server.

This can be solved by making issuer identities global, and tying them to OpenPGP keys.  Doing so has a number of advantages:

  • Each PGP key is unique.  The chance of the same key being generated twice is infinitesimally small.
  • Issuers can sign their IOU definitions (and possibly their IOU tickets as well, though this isn’t compatible with automatic splitting/merging), allowing others to verify their authenticity.
  • AEIOU can piggyback on PGP’s existing web of trust.  Issuers can have their identities verified by other PGP users, so that potential IOU bearers don’t have to do so directly.
  • PGP keys can be used for authentication instead of passwords.

Separate Issuing of Electronic and Paper IOUs

When I added the paper IOU feature, I debated about whether to build it into a separate module from the main electronic IOU issuing application.  I decided not to, in order to avoid having to synchronize issuer accounts across modules.  With global issuer identities tied to PGP keys, this is no longer an issue.  Issuers will easily be able to select entirely different servers for handling of their electronic and paper IOUs, if desired.

Name Changes

Over time, the terms I’ve used have gotten kind of haphazard, simply because of the way that new features were iteratively added and named.  I’d been planning to go through all the code and update the terms used to something more meaningful.  From the old task list:

  • Change terminology:
    • “IOU definition” becomes “IOU type”
    • “IOU ticket” becomes “electronic IOU”
    • “paper IOU ticket” becomes “paper IOU”
    • “ticket stub” becomes “claim ticket” or “transfer ticket” or “transfer certificate” or…
    • “verification code” becomes “authenticity code”
  • Change name of IOU-issuing application to “AEIOU Mint”, in order to differentiate it from other components that will be made later.

I might not go with these exact terms, but you get the idea.


Integrating OpenPGP into AEIOU is a major enough change to justify rewriting the entire program.  Doing so is probably a good idea anyway, as I don’t want to work with raw PHP anymore.  I’m currently leaning towards Python, as it would allow me to use the same language (and reuse some code) when writing desktop client applications for AEIOU.  Regardless of what language I go with, I’ll be using some kind of web application framework with it this time around.

Chaumian Blinding

Some digital bearer certificate systems use Chaumian blinding to protect the privacy of certificate bearers even when they’re not using an anonymity layer to perform transfers.  I don’t fully understand how this works yet, but hopefully by studying the Lucrative/Lucre source code I can figure out how to implement it in AEIOU.


I was laid off from my job this past Tuesday.  Since then, I’ve been even busier than usual, mostly working on my resume and website.  If you’re looking to hire a programmer, or know someone who is, let me know.

I’ll be back to work on AEIOU stuff soon.

Changes Thus Far

There have been lots of small changes made since the first version of AEIOU was released.  I’m just going to cover the more important changes here before moving on.

IOU Definitions

When I started working on AEIOU, I had planned to allow bearers to split a single IOU into multiple IOUs of lesser value, and to merge multiple IOUs into a single IOU equal to their combined value, without intervention by the issuer.  This feature didn’t get implemented in version 0.1, and when I got around to adding it in 0.2, the method that I came up with was kind of a kludge.  Splitting IOUs was straightforward enough, but for merging, the system had to compare the commodity, units, iou_text, and issuer_id fields of each ticket to make sure that none of them differed.

It also didn’t make a whole lot of sense to store the commodity, units, and iou_text fields for every single ticket, when so many IOUs will have identical values for these.  I ended up adding “IOU definitions” (lacking a better term) to the system.  The database for version 0.3 had a definitions table and a tickets table that looked like this:

		create table definitions
			   ( id int not null auto_increment
			   , issuer_id int not null
			   , face_value varchar(255) not null
			   , iou_agreement text
			   , agreement_sha1 char(40)
			   , status enum("active"
			   		,"retired") not null default "active"
			   , primary key (id)
			   , foreign key (issuer_id) references issuers (id)
	') or die(mysql_error());

		create table tickets
			   ( id int not null auto_increment
			   , definition_id int not null
			   , quantity decimal(9, 2) not null
			   , secret_hash char(40)
			   , secret_salt char(12)
			   , primary key (id)
			   , foreign key (definition_id)
			     references definitions (id)
	') or die(mysql_error());

The ticket entries now only store the IOU’s quantity and secret key information, along with the ID of the IOU’s definition.  The commodity, units, iou_text, and issuer_id fields are now stored in the definitions table (commodity and units became face_value, iou_text became iou_agreement).

There’s also an agreement_sha1 field, for storing a hash of the IOU agreement’s text.  The idea behind this, though I never implemented the other half, was that an issuer could link to an IOU definition created by someone else (even on another server), and state that it is equivalent to one of their own definitions.  They would then treat IOUs issued under that definition as though they had the IOU agreement of either definition, at the bearer’s discretion.  This would allow those who trust both issuers to automatically accept a common currency issued by both of them, without having to explicitly choose all IOU definitions that they will accept.  The purpose of the hash is to allow the IOU agreement to be verified to ensure that it hasn’t been changed.

Web Service API

I never intended for users of AEIOU to interact with it primarily through their web browsers.  Doing so would be kind of a pain in the ass, even with a nice interface.  I had planned to write (and hoped that others would also write) various programs, both desktop and web-based, for managing your IOUs, making payments, automatically processing payments, handling “change”, tracking which issuers you trust, negotiating which currency to use in a transaction, etc.  There needed to be an API for accessing all the functions of the IOU-issuing program, so that other programs could interact with it.

Creating an API for a web application (“web service API”) initially seemed complicated: there’s XML-RPC, SOAP, WSDL, etc.  It turns out that many web service APIs just involve taking input via GET/POST parameters (as with a form submission) and returning something machine-readable (typically XML) instead of HTML.  I never managed to finalize the API, but you can see the documentation for the current version (and try it out) here.

Proof of Possession

In version 0.5, I added a feature that allows the bearer of an IOU to prove to someone else that they possess it, without handing over the secret key.  It works like this:

  1. The person that the bearer wants to prove possession to (we’ll call them the “challenger”) generates a random string of characters (the “challenge string”) and gives it to the bearer.
  2. The bearer gives the challenge string and the secret key for the IOU in question to the server.
  3. If the secret key is valid, the server computes a proof string using a keyed HMAC function on the challenge string and the IOU’s “possession key” (separate from the secret key for security reasons).
  4. The server returns the proof string to the bearer, who gives it to the challenger.
  5. The challenger gives the original challenge string and the proof string to the server, which checks them for validity and returns the result.

This feature allows IOUs to be used like stock certificates, enabling the creation of virtual joint-stock companies.  It should be possible to create vote-counting programs, chat rooms, forums, RSS feeds, etc. that use proof of stock possession (rather than usernames and passwords) to authenticate shareholders.

Paper IOUs

I originally intended for AEIOU to be used for the creation of local currencies, specifically for a labor-based currency in Rochester, NY.  This currency was to differ from more common time-based local currencies (such as Ithaca Hours) in that each IOU would be backed by a specific person’s promise to provide labor.  I had hoped that this would alleviate the catch-22 that new local currencies face, by providing a reason for people to accept the currency independent of whether they can spend it as money.

Local currencies need to be easily tradeable in person, not just electronically.  While it might be feasible for some people to carry a handful of IOUs around on a USB stick, and for some sellers to conduct transactions with a computer at their place of business, or with a laptop (netbook?) that they carry with them, we shouldn’t assume this is the case for even a majority of people.

At some point my focus switched towards making AEIOU viable for internet currencies first, so the priority of the “paper IOUs” feature was lowered.  It was finally added in version 0.6.  Here’s the database table:

	$stmt = $database->get_connection()->prepare('
		create table paper_tickets
			   ( id int not null auto_increment
			   , definition_id int not null
			   , quantity decimal(:sigfig, :places) not null
			   , verification_code char(:vcodelen)
			   , primary key (id)
			   , foreign key (definition_id)
			     references definitions (id)

Paper IOUs use the same IOU definitions as electronic ones, but they work differently.  When an issuer creates a paper IOU entry in the system, a verification code is generated for it, and shown only to the issuer.  The issuer then prints the face value, URL, and verification code of the IOU onto paper.  When this paper is given to someone, that person can go to the URL and enter the verification code to ensure that what they have is in fact a valid IOU that is still in circulation.  This cuts down on the feasibility of counterfeiting, because only those who have actually seen the paper IOU can make a copy of it, and copying is more likely to be detected.  The possibility of counterfeiting can’t be eliminated entirely, however, so paper IOUs should only be created in small denominations.

Initial Design

AEIOU is a “digital bearer certificate” system, though I wasn’t aware of that term or of other DBC systems I first started working on the project.  The DBC concept is pretty simple.  For each certificate there is an entry in a database on a server consisting of a unique ID, a password (sometimes the ID is the password), and some information pertaining to who issued the certificate and what they promise to give the bearer in exchange for it.  The issuer exports all of this from the database as a block of text, which is the certificate itself.  When the certificate is given to someone, that person sends it back to the server, which verifies the password.  If the password in the certificate matches the one in the corresponding database entry, the server changes the password and sends the new bearer a new certificate with the new password.  This is done every time the certificate changes hands, so that only the current bearer knows the current password.

This setup is analogous to the use of real-world IOUs (“I owe unto” or “I owe you”).  Someone issuing an IOU writes down what they owe to another person on a slip of paper, signs it, and gives it to that person.  The IOU can then be traded as representative money among those who trust that the issuer will make good on their debt.  When dealing with electronic IOUs, however, it is impossible to distinguish a valid IOU from an illegitimate copy, hence the necessity to “phone home” to the server for every transaction.  Fortunately, doing so over the internet is quick and inexpensive, and there’s no need for the bearer to disclose their identity.

I wrote AEIOU in PHP, and used MySQL for the database, simply because they’re both available on pretty much every web host.  In hindsight, other considerations should probably have taken priority, but I’ll talk about that later.  The easiest way to understand the design is probably to start by looking at the database tables.  In version 0.1, these were quite simple, and matched pretty closely what I described above.  From install.php, the issuers table:

	create table issuers
		   ( id int not null auto_increment
		   , username varchar(20) not null
		   , password_hash char(40) not null
		   , password_salt char(4) not null
		   , id_cookie varchar(30)
		   , contact_info text
		   , primary key (id)
		   , unique username (username)
') or die(mysql_error());

The issuers table stores:

  • id: a numeric ID for each issuer
  • username: the name that is displayed on the issuer’s IOUs and that they use to log in with
  • password_hash and password_salt: an md5 hash of the password with a 4-byte salt
  • id_cookie: a cookie for identifying page requests from logged-in issuers
  • contact_info: a block of contact info text that is editable by the issuer and displayed on their profile page

The IOU entries on the server are referred to as “IOU tickets”, and are stored in the tickets table:

	create table tickets
		   ( id int not null auto_increment
		   , issuer_id int not null
		   , commodity varchar(255) not null
		   , quantity decimal(9, 2)
		   , units varchar(255)
		   , iou_text text
		   , allow_split boolean not null default false
		   , split_minimum decimal(9,2) not null default 0.01
		   , split_precision decimal(9,2) not null default 0.01
		   , status enum("active"
				,"merged") not null default "active"
		   , secret_hash char(40)
		   , secret_salt char(4)
		   , primary key (id)
		   , foreign key (issuer_id) references issuers (id)
') or die(mysql_error());

The allow_split, split_minimum, split_precision, and status fields were unused in this version.  That leaves the following:

  • id: a numeric ID for each IOU
  • issuer_id: the issuer ID of whoever created the IOU
  • commodity: what commodity the debt is denominated in (gold, labor, beans, etc.)
  • quantity: the quantity of that commodity
  • units: what units the quantity is measured in (ounces, hours, cans, etc.)
  • iou_text: a block of text that states explicitly what the issuer owes
  • secret_hash and secret_salt: salted hash of the password (“secret key”) used to transfer the IOU

That’s it for the database.  The actual bearer certificates are called “IOU ticket stubs”, and are generated by the code in stub.php.  Here’s a snippet:

	$stub = '-----BEGIN AEIOU TICKET STUB-----'."\n";
	$stub .= $tdata['quantity'].' ';
	$stub .= $tdata['units'].' of ';
	$stub .= $tdata['commodity']."\n";
	$stub .= 'Issued by ';
	$stub .= $issuer_data['username'].' at ';
	$stub .= $surl."\n";
	$stub .= 'URL: http://';
	$stub .= $surl.'/ticket.php?tid=';
	$stub .= $tdata['id']."\n";
	$stub .= 'Secret Key: ';
	$stub .= $new_key."\n";
	$stub .= '-----END AEIOU TICKET STUB-----'."\n";

The ticket stub would look something like this:

10.00 hours of labor
Issued by chris_acheson at
Secret Key: XZg75rz0gdYF7h7qNpqX

Upon going to the URL listed on the ticket stub, you’d be presented with a page with information about that particular IOU ticket, as well as form inputs allowing you to verify or change the secret key.  The page would display the full statement of what the issuer owes, such as:

I will perform a number of hours of simple labor equal to the face value of this ticket within one week of it being presented to me by the ticket-bearer. Alternatively, I will guarantee the labor of another person, who will work in my stead.

That’s pretty much the extent of the noteworthy features of version 0.1.  In the next post, I’ll cover the highlights of the changes between 0.1 and the current version, 0.6.

Unmet Needs

There are three categories of problems with existing currencies and payment systems that I’m looking to solve with AEIOU: micropayment issues, privacy issues, and trust issues.

Micropayment Issues

Micropayments are very small payments, denominated in units of one tenth of a cent or smaller.  They were proposed as an alternative to the advertising-based business model used by most internet content providers.  The idea is that if, for example, someone operating a website can charge visitors a tiny fee per page viewed or unit of data transferred, they’d be able to recoup their hosting costs and possibly even profit.  Assuming the micropayment system itself is transparent enough, the burden imposed on the site’s visitors is negligible.  Micropayments could also be used to alleviate resource scarcity issues in filesharing networks, wireless hot spots, anonymous proxy/routing networks, etc.

Unfortunately, the promise of micropayments remains unfulfilled.  Existing micropayment systems are either tied to the products and services of the company running them, or require you to sign up with yet another middleman that gets to track your web usage and purchasing habits.  Since most people don’t want the hassle of signing up with a (potentially shady) micropayment service just to spend $0.0047 on reading a couple dozen pages of a single webcomic, content providers just opt for ads instead.  Micropayments need to be a feature of the same payment systems that people use for larger purchases.  They need to just work, without extra effort on the purchaser’s part.

Privacy Issues

Ideally, an electronic currency should be as cash-like as possible.  You should be able to keep your transactions secret from those who do not participate in them.  You should also be able to keep secret the amount of the currency that you possess.  As far as I’m aware, there is no method of transferring major national currencies via the internet while keeping the transaction secret.  Payers can use pre-paid “credit cards” to keep their identities secret, but this incurs hefty fees, and does nothing to hide the payee’s identity or the transaction itself.

The privacy situation is slightly better with alternative currencies: some “digital gold currency” services allow users to hold accounts without disclosing their identity, or do not bother to verify identities.  One could also (in theory) use a time bank system pseudonymously, depending on the policies of those running the system.  The problem with both of these is that they’re still based around accounts.  The system administrator can see every transaction that each account participates in, even though they may not be able to tell who owns the accounts.  This is very weak anonymity, too.  Someone analyzing the transaction data for an account may be able to correlate it with its owner.  Alternatively, if the account owner makes a non-anonymous transaction (by giving a shipping address, for example) with anyone, the other party to the transaction can reveal this ownership to others.

Systems based on “digital bearer certificates” don’t have this problem, as they lack any sort of accounts.  These are probably the closest analogue to cash that can be achieved with an electronic currency (I’ll explain how they work when I get around to talking about AEIOU’s design).  Trouble is, existing DBC systems are a bit lacking.  Ricardo is closed-source and defunct.  eCache is closed-source and limited to a single issuer.  iCASSH is closed-source, limited to a single issuer, and possibly defunct.  Without a robust open-source implementation, the DBC currency market will remain stunted.

While writing this, I did manage to find two open-source DBC systems: Lucre and Lucrative (which is based on Lucre), though both projects ceased development many years ago.  The source code for Lucrative is still available on SourceForge, so I’ll spend some time later and see what design ideas I can glean from it (yay open source!).

Trust Issues

Quite frankly, fiat currencies should not be trusted.  I’ll refrain from the broader argument that governments generally should not be trusted, and merely point out that governments that issue fiat currencies tend to maintain, as a matter of policy, a steady rate of inflation.  This effectively transfers wealth from the majority of the population to those who are wealthy and politically connected, as well as to the government itself.  Inflation is achieved by increasing the supply of the fiat money in question.  The inflationary effect is not uniform:

New money injected into the economy has an inevitable ripple effect; early receivers of the new money spend more and bid up prices, while later receivers or those on fixed incomes find the prices of the goods they must buy unaccountably rising, while their own incomes lag behind or remain the same.

Once wages do catch up to prices, wage-earners are pushed into higher income tax brackets and end up paying more taxes, despite not receiving any more real income.  Governments issuing fiat currency have too much of a conflict of interest to be trusted with the maintenance of that currency.

As an alternative, consider a representative currency, backed by a specific commodity and issued by any number of independent parties.  These issuers would sell units of this currency for the price of the backing commodity, plus a fee to cover their cost of operation.  Unlike with fiat currency (where the issuer has a captive market, due to tax requirements), it’s in the interest of each issuer not to devalue the currency units that they issue.  If they do, they’ll simply end up losing their customers to their competitors.

How to Make Money

What exactly is money, and how does it get its value?  The concept is simple enough, but there’s a lot of confusion surrounding it.  Money is any good that is generally accepted as payment.  Currency, by contrast, is a specific medium of exchange (US Dollars, Japanese Yen, Ithaca Hours, Beenz, etc.), created specifically for use as money.  However, just because a currency is intended to be used as money doesn’t automatically make it so.  If people don’t value a currency enough to accept it as payment, it isn’t really money.  So how does money come to be valued in the first place?

Commodity money is the simplest and earliest answer to this value problem.  Commodities such as gold, salt, cigarettes, and barley have at times seen widespread use as direct forms of payment.  Since the commodities themselves are already valued, the payee doesn’t have to worry about whether they’ll be accepted as payment by others.  Closely related is representative money, which consists of tokens (coupons, certificates, etc.) that can be redeemed for a fixed quantity of the commodity that the token represents.

Fiat money is what we typically use today.  Currencies issued by national governments are fiat currencies.  They are usually not intrinsically valuable or redeemable for valuable commodities.  What makes a fiat currency valuable is that the issuing government accepts (and typically requires) it for payment of taxes.  This generates enough demand to keep the currency viable as money.

There have been numerous attempts to introduce local currencies and promote their use as money, with varying degrees of success.  Some of them are or were localized versions of fiat currency (backed by local governments) or representative currency (such as company scrip).  Most lack any backing at all.  This is the case for Time Banks, LETS, and currencies styled after Ithaca Hours.  To the extent that these currencies are successful, they achieve their value from local enthusiasm, as well as from the donations and activist labor which maintain the project and provide free advertising for participating businesses.

While it is possible to use AEIOU to create unbacked currencies (or even fiat currencies, assuming there’s some sort of government backing), its design is centered around creating (representative) commodity currencies.


AEIOU is an open-source system for creating electronic commodity currencies.  I’ve been working on it off and on (mostly off) since 2006.  After yet another hiatus, I’ve decided to get back to work.  However, I’d like to take a different approach this time.

Quite frankly, I’m a little bit embarrassed at the relatively meager progress I’ve made in the past two and a half years.  Of course, my sluggishness isn’t really all that surprising.  This is the only serious PHP project I’ve ever done, and I’d never dealt with web services before either.  Additionally, while the core component of AEIOU has technically been usable for a while now, it’s only a small part of the overall framework that I want to create.  Overall, it’s an ambitious project, and I often wonder if I’m making bad design decisions which will have disastrous consequences later on.

I had hoped to find other developers interested in working with me on this project.  I figured this would alleviate some of the aforementioned problems, speed progress, and generally keep me motivated.  A few people have expressed interest, but nothing has come of it.  Part (most?) of the problem here is that there isn’t an easy way to get familiar enough with the project to actually start working on it.  Other than what’s been implemented in code, the design is almost entirely in my head.

Which brings me to the purpose of this blog.  In future posts, I’ll attempt to detail the current design of the existing AEIOU code, as well as the overall design that I have in mind for the whole system, and ideas for possible changes.  I’ll also explain why I see a need for this project, and what I hope to achieve with it.  What I want from you, dear reader, is feedback.  Tell me where I’m “doing it wrong”, give me suggestions, or whatever you like.  I’d like to hear from more experienced web developers than myself, but also from anyone interested enough to read this.

Anyway, here’s some links to start things off: