Each (human) user of the system should have an amint server. Autonomous processes attach to the server as clients. There is also a gui client which can be used to make payments, create additional owners, or transfer coins between owners.
The amint server is a java app that sits on top of a mysql server. I've only tested it with mysql, but I don't know of any good reason why other sql servers wouldn't work. Right now the server and clients communicate over a port, but a pipe should work just as well.
Entities exchage coins and other information in the form of xml documents. Right now there are three sorts of documents in the system
Mint Info documents are created by mints in order to give the amint servers the information they need to interact. Mint Info douments are signed by the issuing mint. The signed information includes the name of the currency, the export name, the public message key, current coin keys, and a list of web services offered by the mint and their corresponding urls. Mints use the same size and type of key for mint messages and for all coin denominations. There's no particular reason they have to, but I can't see any good reason why they shouldn't.
Payments are a set of coins of a particular type from a particular mint. There is no signature on a payment document, although the individual coins contain signatures. There are many possible payment types:
Mint Messages contain human-readable statements from a mint. For example, instructions as to how someone might go about aquiring coins from a mint and what they might be useful for should probably go in a mint message. Mint messages are signed by the issuing mint.
a mint may be identified (depending on context) in several ways.
Each mint has a public-private key pair. The mint can issue information signed with its private key (for example, new coin keys), and traders can verify that the information actually came from that mint using its public key. Because there is no central authority in the system, the message key (or, technically, the hash of the public message key) is used as the inter-user identifier of the mint. That is, a payment contains the key-hash as the mint identifier. For this reason, the message key cannot be changed, If a mint must change its message key, as far as the system goes it has become a new mint.
An export name is a short, human memorable name a mint uses to refer to itself (example: steamingbuffalo). Because there is no central naming authority, there is nothing to prevent multiple mints from using the same export name. However, it is a really bad idea to deliberately use a name which another mint is known to be using. In particular, nobody except me should use the export name "steamingbuffalo".
A user can create a "nick" to refer to a mint on his own system. Usually he probably should use the export name, unless there's a good reason not to. This nick will not necessarily mean anything to anyone else.
This is an integer the amint server ses internally. It won't mean anything to anyone on another system, but clients can use it to identify mints.
A client connects to the amint server as a particular owner. A new owner should be created for every autonomous process or group of process which are intnded to share coins. There is one special owner called "amint_root" which is allowed to create additionl owners, change owner passwords, destroy owners, transfer coins between owners, and do other admin stuff.
A mint operated by a server also has a particular owner, but mint info is not owned.
A mint has a separate key for each coin denomination. The lowest denomination must be 1. When a mint creates a new set of coin keys it should list them in ascending order.
Because the mint must keep track of all spent coins, a mint may wish to occasionally issue a new set of coin keys and (after some time) no longer accept coins signed by the old keys, at which time it can delete the old records.
The system currently supports two types of coins (one format for each).
Single-pass coins are straightforward. A coin identity is just a random binary string of a sufficient size to avoid accidental collisions (say, 16 bytes). In order to spend a coin :
The currently supported format for rippable coins is called 3SIG. A coin has a "left half" and a "right half" which are signed separately. In order to spend a coin :
In this particular implementation the identity of the left half is number which is equal to modulo three, the identity of the right half is 1 + the identity of the left half, and the verification code is the signature of 2 + the identity of the left half. The requirement of the left and right halves is to prevent a dishonest customer by separately spending the two halves as if they were "left halves" of separate coins.
a mint can advertise various network services. Currently two are recognized:
A web page (html form) where merchants can exchange spent coins and protocoins for new coins, either by pasting the payment file or the server can access the web page directly.
an url which contains the current Mint Info document.
Right now there is a command-line client, a gui client, and a couple client perl scripts.
The command line client is very hard to use (basically all it does is pass strings through from the console to the server and back again). Largely just a proof of principle thing.
The perl scripts are also largely proof-of-principle. There's a script that just generates new free coins, and one useable for auomatic web exchange.
The gui client will download a list of all mints known to the owner upon login. To select a mint as active, select "view mints" and then just click on the desired mint in the table. If the "owner" logged in is the owner of the selected mint, "create payment" will allow creating new coins out of nothing. Otherwise, it will show the list of coins, which can be clicked individually to add them to the payment (if they are from the correct mint).
The gui will perform certain payment transformations automatically. For example, upon recieving a "left_pay" payment it will automatically generate the corresponding "left verify" payment.