[cap-talk] Comments on a paper
szabo at szabo.best.vwh.net
Wed Jul 6 01:10:41 EDT 2005
> >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
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.
> 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
> 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.
More information about the cap-talk