A stab at the sealer in E

Tyler Close tyler@waterken.com
Tue, 9 Nov 1999 18:45:23 -0500

Hal Finney wrote:
> I would think you could do it either way.  Create
> the object at the time
> the blind token is created, and put it in a pool,
> then return one of
> the objects when the token is presented. Or
> else, wait and create the
> object at the time the token is presented.  With
> the latter approach,
> you could increment a count of outstanding
> objects at issuance time,
> if you wanted to check for the possibility of
> there being more tokens
> presented than outstanding objects, which
> shouldn't happen.

The key difference between these two approaches is that
deleting and then re-creating the eright would require
access to the Mint. If you use a pool, then you do not
require access to the Mint. This means that your 'blinding
agent' could offer blinding services for any eright, not
just those that agreed to be blinded by giving the 'blinding
agent' a capability for the Mint. This might have important
legal as well as practical consequences.

In terms of runtime performance, there is no difference
between the two approaches. Erights are never reified as
actual objects. A Purse keeps track of its contents using a
counter as you suggested; therefore, in storage space, the
pool would be just a counter.