[cap-talk] Capability accounting

[Norman Hardy]

On Jun 21, 2006, at 9:59 PM, Ian G wrote:

> Jed at Webstart wrote:
>> All,
>>
>> If others aren't interested in this topic (e.g. think it a waste of
>> time), why so?  E.g. because there isn't enough capability
>> infrastructure to account for (e.g. wideword?), because
>> capability mechanisms don't need accounting, because there's
>> some other clear and better way to do it, or what?
>
>
> As I hale from the digital money side, I see "accounting"
> as a poor copy of digital money.  Although it is interesting,
> I probably would always model it as a money problem.  Then,
> the accounting view tends to disappear.

I am extremely enthusiastic about introducing money into the system.
DSR <http://cap-lore.com/Economics/DSR/> even includes a 32 bit
money amount in most network packets.

There remains a place for establishing reservations however.
The various futures markets display this value.
I may shop around for one machine where I can buy enough resources
to do a $10,000 calculation.
If I find such a machine I will buy futures at a pre-negotiated price
rather than merely hope that price won't rise before I finish.
It called hedging.
Another example is scheduling a scarce cross country video channel.
I am arranging a meeting that can be virtual if the channel is  
available.
I must know a week or so in advance if I can buy a future on the  
channel.
Agorics is a recent company that tried to exploit some of these  
features.

Here <http://cap-lore.com/CapTheory/Dist/Found.html> is a fairly  
detailed
description of a network architecture that includes capabilities and  
money.
It is a cartoon architecture that needs much fleshing out.


>
> One thing that pushing things into a money framework does
> is to more clearly show how value is being used and allocated.
> This is often "bad", because it shows that certain things
> are really hard to get going as money problems.  E.g., the
> "micropayments" guys would get all gooey about the notion
> of charging micropennies for a capability.  But if they were
> to try and build it they'd discover that there are hard
> transaction costs which break the paper model;  that is, it
> isn't worth charging for something below transaction costs,
> and often there aren't enough sales above the transaction
> costs to make it worth doing.

Above link addresses some of these points.

> Money makes all those things come to the fore.  The accounting
> people will say "oh, we don't need those costs, we'll just
> run an accounting system," but the accounting system *hides*
> the costs somewhere, rather than eliminates them.  So this
> only works if you can find a place to hide them.

Agreed!
Trouble with most accounting systems is that they spend more on
accounting transactions than on service.
For quite some while some telcos spent more money remembering
and providing you with a printed itemized listing of your calls, than  
they
spent to switch and carry the bits in the phone calls.

> Hence, most Internet systems are built without any accounting,
> and without any money.  Then, when we discover where the real
> shortages are, we get around to experimenting with the accounting
> and / or money.
>
> (I don't know whether you actually got that far in your developments,
> I spotted that one of you mentioned it was an up-front requirement.)
>
> iang
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk