[cap-talk] Capability accounting - meta

Nick Szabo szabo at szabo.best.vwh.net
Tue Jun 27 17:00:14 EDT 2006


Ian Grigg: 
> (And, the coins paridigm might be considered to
> be closer to the caps idea, in they they are
> handed around and they are their own value /
> control.  I'm not sure that's a useful notion
> however, as one could say the same thing about
> the payment instructions.)

David Chaum worked on capabilities before he invented
blinded digital cash.  Capabilities undoubtedly helped
to inspire this idea, but he (as I) thought modern 
cryptography, which goes far beyond mere encryption and 
digital signatures, makes far more and better kinds of 
distributed security possible than mere capabilities
or mere traditional encryption make possible.  He thus abandoned 
his work on capabilities and neglected traditional encryption
to focus on modern cryptography, in which he became the 
leading pioneer.  It's still quite worthwhile studying almost 
any of the dizzying array of protocols he invented, many 
of which are starting to come off-patent.  Blinded 
signatures are just the tip of the iceberb.  Almost all of 
these protocols involve transferring information or 
authority in ways capabilities and traditional encryption 
can't do.

Especially in the context of resource allocation,
it's profitable to compare capabilities to the following 
(which doesn't involve any fancy cryptography beyond
the optional blind signatures):

http://szabo.best.vwh.net/scarce.html

One might look at this in the following way: that the idea
with scarce objects is that accounting too should be 
object-oriented.  Let objects do their own accounting.
The objects can also thereby protect themselves from
denial-of-service attacks.

Scarce object clients face the same mental transaction cost 
problems as any other micro-accounting or micropayment scheme
faces.  And I think to the extent one can solve these
(for which I propose the market translator) one can
solve the coincidence-of-wants problem with standard
and widely used services as well.   Thus I don't see 
much problem in a mature system with using micro-barter
rather than micro-currencies.  Even less is there
any need for software to distinguish between the two,
since any widely used and trusted barter token can 
serve the function of money in solving any 
remaining coincidence-of-wants problem.


Nick Szabo
http://szabo.best.vwh.net/
http://unenumerated.blogspot.com/


More information about the cap-talk mailing list