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:
mysql_query('
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());
mysql_query('
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:
- 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.
- The bearer gives the challenge string and the secret key for the IOU in question to the server.
- 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).
- The server returns the proof string to the bearer, who gives it to the challenger.
- 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.
Recent Comments