[cap-talk] Capability accounting

[Nick Szabo]

Ian Grigg: 
> What it does run slap bang into is the decision
> threshold which Nick is talking about.  If you
> ask the user "shall I pay for this Cap, it
> costs 0.001 cents" you just blew it, because
> you consumed 0.01 cents of the user's time.

If the user's opportunity cost is $60/hour
and you take 6 seconds of the user's time, that's a
mental transaction cost of 10 cents.  And that doesn't 
even count the cost of a distraction interrupting
the user's train of thought, which is often far higher 
still.

Furthermore, if you _don't_ ask the user then 
you probably lack the preference information on which 
effective market pricing and many other resource 
allocation and security schemes depend.  And even 
if you do ask the user, but the user just makes a 
hasty random decision rather than contemplating 
or thinking about it, then the resource allocation 
or security scheme is still not getting very much 
useful information.  

If you ask the user to make petty decisions, the user will grow
disgusted at the distractions and go use some other system. 
If you don't ask the user enough important questions, then you 
probably lack the preference information on which good resource 
allocation and security depend.  That's the conundrum which creates 
the mental accounting barrier to micropayments.  Since the user to 
avoid mental transaction costs prefers to specify his preferred price 
in big and simple chunks, (doesn't want to be "nickled and dimed"), 
there's not much point in a money system where payments can be 
made in much smaller chunks, and this is why after tens of
millions of dollars of investment and more than a decade of 
hoopla none of the dozens of micropayment schemes have succeeded.
For the same basic reasons, it's usually counterproductive to ask 
the user to make small security decisions.

In some situations you may be able to infer preferences that
a reasonable or average user might have (and computer resource 
allocation and security schemes, like the old Soviet Union's 
central planners, do this all the time), but resource allocation 
designs, including those that nominally look like markets but 
still lack good preference input, would be far superior if they 
made their preference assumptions explicit and recognized the 
limitations of the approach.

Sometimes one can obtain preferences that users already input 
into devices, as in the following example of the price-sensitive 
thermostat being tried in California:

http://unenumerated.blogspot.com/2006/04/smart-contracts-reduce-mental.html

I recall that some here have argued that a good cap system simply 
looks at normal user input and infers security preferences
from it.  I concur with that sentiment, because it economizes on
mental transaction costs.  But would help for designers to make more 
explicit the assumed relationship(s) between input and security 
preference; such inferences may often be faulty.

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