Separation of duties in issuance of "digital bearer certificates"
also known as, the Systemics collaborative mint arrangement, or the 5PM (five party model).
(unofficial description by an amateur Mint trustee)

A digital bearer certificate (DBC) is an encrypted and/or signed data file, that is a sort of warehouse receipt for some valuable thing such as currency or gold, the ownership of which is registered in an issuance server someplace.  The technology by which DBCs are transferred (spent) from one party to another, varies somewhat between different service providers of electronic money. 

This 5PM model describes five roles, which provide some semblance of common sense and internal control over various risks to people relying on electronic money (or commodities, etc. -- DBCs. )

The 5PM is offered as a potential starting point for discussion of more rigorous regimes of internal control, capable of achieving robust digital cash within webs of trust both within central issuance servers and decentralized P2P communities of issuers.

This model disregards DBCs having no issuer, since data itself is meaningless without a redeemer of last resort.  This model is is a trust model which focuses on the Issuer, as the first mover, the redeemer, and the sole "executive" in control of creation of DBC. 

Here is a high level overview of the 5-role model: 

The "Issuer" is the CEO or entrepreneur who runs the electronic issuance operation. Truth be told, the Issuer could perform all of these functions.  The goal in inserting additional people is to make fraud more difficult, requiring collusion to succeed. 

At the bottom of this page, please review the draft contract between Issuer and the Mint Trustee in an actual issuance (PicoIPO).  Below, is a UML sequence diagram of the duties of the Mint Trustee (me. )

When the other guys clarify more exactly what their duties and procedures are, I will be happy to produce additional UML diagrams. 

Please observe, the following "Trial Balance" report.  This comes from the server software (operated by the System operator).  This is one evidence relied upon by the Mint trustee in performing the Mint role.  First of all you have to understand what a "hash" is a fingerprint or signature, of some underlying piece of data.  For example your name.  Or the gettysburg address.  The SHA hash, is a mathematical formula that generates a big long series of numbers that are almost impossible, to have come from any other data besides your name... In the Ricardian server uses hash numbers instead of anybody's name because it is just as good as the name, and in the case of accountholders, the SHA hash happens to be the public key of the accountholder. Why use anything else but their digital key, since that is what matters anyway?

The existence of an account with its hash value, illustrates that Issuance server knows that particular Webfunds client instance, such as the Webfunds hash identity of the Mint and Manager.  Webfunds clients create their own keypairs.  The keypairs are not managed by the Ricardian server.  The server establishes an account for whatever Webfunds client comes in out of the ether, and declares its public key. 

Once the Mint and Manager person accept their roles, their accounts on the Issuance server are "switched on" at the server to give them special powers nobody else has: the Mint person can create unbalanced entries out of nothing, using Webfunds client.  If anybody other than Mint (SHA#98e...) tried to create a payment with Webfunds, in excess of their balance in their Webfunds wallet (value of instruments he has been  paid), they would of course be rejected by the issuance server.   Manager's special powers includes being able to receive payments  invented by Mint.  Money invented by Mint can only be given to Manager.  Server software does not allow Mint to make any payments to anybody other than Manager. 

Systemics Issuance Server
Trial Balance
Issuer: PicoIPO SHA:e7897df4fea3375ba1de4b0f13e91891988d8bf8

Here is another evidence relied upon by the Mint trustee. The Mint confirms that real metal has been bailed into the warehouse (the Repository) as backing for the PicoIPO DBC:

Below is what the WebFunds software looks like, on the Mint Trustee's desktop, immediately after creating a DBC data file, i.e. the minting of 9 units (which might be 9 grams, 9 dollars, etc. )

Prior to this point, I used a function of the WebFunds software to create a DBC datafile representing 9 grams.  At this point below, I have just pasted the datafile into the first window, and you can see it is just ASCII text, and it is still highlighted because I just finished pasting it here. This being, the place for commanding the Ricardian Server to give my money to somebody else (the carnal act: the Spend. That is the only thing you can do with WebFunds.  Other people can "Spend" to you, and you can only "Spend" to others.) 

In this case, I have deposited the payment into my own wallet.  Nobody else could do this act, except the WebFunds instance designated by the Issuance Server as that of the Mint Trustee.  If anybody else tried to create a payment in excess of the money in their wallet, they would not get the happy message I received "Deposit ..is good."  They would get an error message.  (The Issuance Server also will NOT allow the Mint Trustee to make any payment to anybody whatsoever, other than the Manager within the 5-role model, i.e. the Manager of the minting process.) 

Draft Contract

1.  This is an agreement between PicoIPO Ltd (the "Issuer") and
Todd Boyle (the "Mint").

1.a  The date of this agreement is .......

2.  Mint agrees to the following:

2.a  Mint will create a WebFunds account specially set aside
     for the creation of float.

2.b  Mint will duly notify the Issuer, and thus the Operator,
     of the account's details, generally by sending a zero payment.

2.c  Mint will only create float as per instructions from the
     Issuer.

2.d  Mint will write payments for the generation of float
     only to the instructed manager's account.

2.e  On receipt of instructions, Mint will compare the request
     to the terms and conditions of the named Ricardian Contract as a
     sanity check.

2.f  payments sent back to the Mint for the purpose of retiring
     float will be returned to the Mint account.



3.  Issuer agrees to the following:

3.a  Issuer will instruct Operator to set the Mint account as
     capable of creating float.

3.b  Issuer will send signed instructions for creation of
     float, including target account of Manager.

3.c  All instructions will be sent in accordance with the
     Ricardian Contracts so named.



4.  Both sides agree that

4.a  The users are a part of the auditing process, and are encouraged
     to participate.

4.b  In general, the relevant auditing information is to be made public.


5.  In compensation, the Issuer will ....


Signed,

Todd Boyle                                Bob Nugent,
Mint                                     for PicoIPO.

Below this line are random bits and junk under construction. Don't go there.

Date: Fri, 21 Jun 2002 09:28:40 -0400
To: dgcchat@lists.goldmoney.com
From: Geoffrey Turk <*****@goldmoney.com>
Subject: [dgc.chat] GoldMoney Perspective on SR

A number of people have asked about our perspective on the recent demise of
Standard Reserve. We've posted the following in response:
http://www.goldmoney.com/press-release/pr_2002-06-19.html 

I'd like to add that GoldMoney is the only DGC in which the controller of
the currency (i.e., the person who adds/removes value in the system and
ensure the exact balance between GoldGrams and grams of gold) is an
entirely independent party: Euro-Dutch Trust. Further, GoldMoney is
designed such that public key cryptography ensures that only EDT can
perform this role. This is just one of the governance procedures that have
been put into place for GoldMoney, and we continue to enhance and expand
these procedures as the amount of gold circulating as GoldGrams in the
system increases.

Regards,
Geoff Turk
Director of Operations - GoldMoney