Peter Denning has written somewhere that the confinement problem couldn't be solved because a channel to record billing information could also transmit proprietary data. We demonstrate here that this is not a serious problem.

First Idea

Collector provides a trustworthy hole thru which payments in the form described in (purse) may be sent by a program to the program author while limiting the information flow.

Col keeps an association between 8 byte deposit names and purses. For each of these purses P it holds an amount of money am(P).

Col(collector__establish_purse{=0};P==>c,((8,nm)))

If P is a valid purse and am(P) was >=505 then c = 0 and nm will become associated with P. am(P) will be decremented by 500.

If P is a purse but am(P) < 505 then c = 1.

If P is not a purse then c = 2.

Col(collector__disestablish_purse{=1},((8,nm));P==>c)
If nm is associated with P then the association is ended and c = 0. am(P) is incremented by 450 and funds due to be deposited in P are forfeited.

Cold(cold__deposit{=0},((8,nm),(4,x));P==>c)
If am(P) >= x + 6 then x+1 is withdrawn from the amount of P and x is added to the collector's account for eventual deposit in the purse associated with nm.

Interest may be paid on this account.

Each month the money held in account for each registered purse is rounded down to a multiple of 1000 and that multiple is deposited {perhaps with interest} in the associated purse. That multiple is deducted from the account. If there have been no deposits to the account during the month, the entire amount is deposited.

See (p3,sdc) and (p3,ch-fact) about ideas in this area.

Suppose that in a factory whose .program is for hire, there is a component that is a requestor's key to another factory P that produces a "pay channel". P would have as a hole, the key Cold described above. P would also have as sensory data components the eight byte code identifying the payee's purse.

Question: Is there an advantage in this scheme? It hides the 8 byte id. So what?