[cap-talk] Comments on a paper

Nick Szabo szabo at szabo.best.vwh.net
Wed Jul 6 01:10:41 EDT 2005


I wrote:
> >scarce objects:
> >
> > http://szabo.best.vwh.net/scarce.html
> >

Alan Karp responded:
> The architecture described in this write-up is similar to the one in the
> paper I cited, with some significant differences, though.  Nick shows
> one Transfer Agent per Issuer.  The cited paper allows several Transfer
> Agents per Issuer. 

I don't talk about this in the paper, but one can replicate the "spent 
list" and thus have multiple Transfer Agents per Issuer.  For that 
matter, one can replicate Issuers and replicate the objects (Providers)
themselves.  Techniques for such replication are well-known, but not
necessarily cheap.

Alternatively, the Issuer can subdivide the resource among different 
Transfer Agents, in which case replicating the spent list is not needed.

> Nick's version is one-level, i.e., the Transfer
> Agent grants rights to the Ticket Client. 

Nope, it's open-ended -- Ticket Clients can transfer object references
to other Ticket Clients using online clearing with Transfer Agents.

> In the cited paper, the
> Transfer Agent could also grant rights to other Transfer Agents. 

Trivially, a Transfer Agent can also be a Ticket Client and thus
grant and be granted rights.

> Nick's
> architecture is designed to conserve claims on the resource.  The cited
> paper specifically encourages producing tickets for more resource than
> is available. 

With scarce objects it's easy enough to overissue if you think your
reputation will get away with it.  Call it "fractional reserve 
programming."

> Nick's solution is clearly simpler, but it doesn't address the goals set
> out in the paper I cited.

The above goals can be addressed far more simply and effectively 
with scarce objects.  

Nick Szabo
http://szabo.best.vwh.net


More information about the cap-talk mailing list