[cap-talk] IOU Protocol

[Toby Murray]

On Fri, 2009-01-09 at 07:53 -0800, Mark Miller wrote:
> If you'd find it useful, I'm happy to extract an IOU only
> implementation from the current E code. I'll leave it to Tyler though
> whether to deem that a reference implementation ;).

Hi Mark,

Wow that would be really useful indeed. From skimming the code, am I
right in assuming that the basic idea is to have a sealer/unsealer for
each brand of credit/rights. Then
 - All holds created by accounts issued for this brand are sealed with
the brand's sealer. 
 - The sealer/unsealer is held by the Terms object, allowing only it to
perform transfers between holds of the corresponding brand of credit.
 - A Hold, once unsealed, can do one of two things: add to its contents
or empty itself
 - A transfer from one hold to another proceeds by unsealing the src and
dest hold, having the src hold empty itself and filling the dest hold
with the amount emptied from the src hold. 
 - An Account must keep track of the total assets held in all currently
valid child holds to avoid "oversubscription"

Have I missed anything? 

Does the E implementation make use of E's eventual-send semantics at all
to enforce any of its security properties, or can the entire thing be
built using only immediate-sends?

The implementation in DonutLab bundles the Terms object with each
Account object via the AccountMgr interface. Does this mean it loses
some of the benefits of straight IOU (basically emulating ERTP in which
the right to transfer and the right to own credits is not separated)?

Is anyone aware of any other (now defunct) IOU or ERTP implementations
that have exited in other object-capability systems? I read somewhere
that ERTP was derived from the KeyKOS space bank protocol, or something
related. Is this described anywhere? (It is a good contrast since it's
implemented on (or for, I'm not sure which) an object-capability OS
rather than a language like E.

Cheers again

Toby