Separation of duties in issuance of “digital bearer certificates”
Also known as, the Systemics collaborative mint arrangement, or the 5PM (five party model).
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. 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
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 that4.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.
