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.
Tyler