Micropayments: myth?

Some electronic commerce projects promise dramatically lower transaction
costs, so that we can achieve "micropayments", "microintermediation",
and so forth.  Is this achievable?  

Consider a feature fairly independent of the particular payment system: 
the statement of charges.  Here lies a tradeoff here between completeness 
and complexity.   On the one hand, merely summarizing charges creates 
the opportunity for salami frauds, allowing widely distributed false or 
exaggerated microcharges to go undetected.  Furthermore, parties reading 
only the summaries get no feedback by which they can adjust their behavior
to minimize costs.  On the other hand, a statement too complex to
be easily read also allows fraud, error, and inefficient usage to 
go unrecognized, because one or both parties cannot understand the 
rationale for the charges in relation to the presumed agreement on
terms of service and payment. 

There seems to lie here a fundamental cognitive bottleneck, creating a
limit to the granularity of billable transaction size whether electronic
or physical.  One proposed solution to this has been "intelligent 
agents".  But since these agents are programmed remotely, not by the 
consumer, it is difficult for the consumer to determine whether the agent
is acting the consumers' best interests, or in the best interests
of the counterparty -- perhaps, necessarily, at least as difficult 
as reading the corresponding full statement of charges.   By
sleight of hand we may have merely transformed the language of 
the transaction as it needs to be understood by the party, without
reducing the complexity to be understood.  Furthermore, the user 
interface to enable consumers to simply express their sophisticated 
preferences to an agent is lacking, and may represent another fundamental 
cognitive bottleneck.

Telephone companies have found billing to be a major bottleneck.
By some estimates, up to 50% of the costs of a long distance call
are for billing, and this is on the order of a $100 billion per year
market worldwide.  Internet providers have been moving to a flat fee in 
order to minimize these costs, even though this creates the incentive for 
network resource overusage.  

A micropayments system assumes a solution to the billing problem.
If somebody could actually solve the this problem, rather 
than merely claiming to have solved it via some mysterious
means ("intelligent agents", et. al.), the savings would be 
enormous even in existing businesses such as long distance and
Internet service -- never mind all the new opportunities made
possible by micropayments.  

Nick Szabo
szabo@netcom.com
http://www.best.com/~szabo/

I believe that micropayments will revolutionize business
transactions, and that they are entirely feasible, and have
written on the subject on cpunks intermittently. NS starts
out with some opposite assumptions, which I don't really
think are entirely plausible.

>Consider a feature fairly independent of the particular payment system: 
>the statement of charges.  Here lies a tradeoff here between completeness 
>and complexity.   On the one hand, merely summarizing charges creates 
>the opportunity for salami frauds, allowing widely distributed false or 
>exaggerated microcharges to go undetected.  Furthermore, parties reading 
>only the summaries get no feedback by which they can adjust their behavior
>to minimize costs.

dunno what you are talking about here. with micropayments, why would
you necessarily have statements? you're using an old billing model
on a new paradigm. please establish a *context*. it would be ridiculous
if people submitted "microbills" to companies that responded with
"micropayments". that's the wrong model.

here's how people are talking about micropayments. imagine that
you see a link with a little 5c sign next to it. that means when
you click on it, you are automatically debited 5c. your own browser
can handle keeping your own records. the transaction occurs when
you hit the button. the idea of a bill being submitted, that you seem to
be suggesting with your idea, doesn't make sense. another example:
downloading an FTP file.  the whole idea of billing is thrown away
in favor of immediate processing.

  On the other hand, a statement too complex to
>be easily read also allows fraud, error, and inefficient usage to 
>go unrecognized, because one or both parties cannot understand the 
>rationale for the charges in relation to the presumed agreement on
>terms of service and payment. 

again, this doesn't make sense at all to me. "statements, bills, 
summaries"-- these are all things you require for larger size
transactions. if after a day of net surfing I have spent $3.16,
and my browser kept a record of every case where I paid it out,
what's the problem? the browser does not pay unless I click somewhere.
nobody submits bills to my browser.  all actions are initiated by
me.

>There seems to lie here a fundamental cognitive bottleneck, creating a
>limit to the granularity of billable transaction size whether electronic
>or physical.

"fundamental cognnitive bottleneck"?? not in my brain. perhaps you
should check your own equipment <g>

  One proposed solution to this has been "intelligent 
>agents".  But since these agents are programmed remotely, not by the 
>consumer, it is difficult for the consumer to determine whether the agent
>is acting the consumers' best interests, or in the best interests
>of the counterparty -- perhaps, necessarily, at least as difficult 
>as reading the corresponding full statement of charges. 

it doesn't make sense at all for one to give autonomous capability
to agents to spend money, at least until they have been refined.
I don't see where agents fit into this all in the beginning. you're
putting the cart before the horse. I've never seen micropayments
discussed in the context you are putting them in. (no wonder it
is causing you "cognitive dissonance"). the uses you cite may not
appear until long into the future. in the meantime the model I wrote
about above has no problems you cite that I can tell.

  By
>sleight of hand we may have merely transformed the language of 
>the transaction as it needs to be understood by the party, without
>reducing the complexity to be understood.  Furthermore, the user 
>interface to enable consumers to simply express their sophisticated 
>preferences to an agent is lacking, and may represent another fundamental 
>cognitive bottleneck.

you are tackling a different problem. "how can we get reliable agents
that can be trusted with buying decisions". this has nothing or little
to do with "the feasibility of micropayments". micropayments are not
necessarily tied to agents.

>Telephone companies have found billing to be a major bottleneck.
>By some estimates, up to 50% of the costs of a long distance call
>are for billing, and this is on the order of a $100 billion per year
>market worldwide.  Internet providers have been moving to a flat fee in 
>order to minimize these costs, even though this creates the incentive for 
>network resource overusage.  

imagine a user who controls his own wallet. he knows when he is paying
from that wallet. you seem to have this idea that outsiders could
make queries to that wallet that would be hard for the consumer to
keep track of. this makes no sense to me. the wallet action will always
be tied with some other action. the user picks up the phone to dial
somewhere, and it says, "that will be .3c-- will you pay"? he says
yes. 

>A micropayments system assumes a solution to the billing problem.

as I wrote, I don't imagine a billing system at all in terms of
micropayments. its the wrong model. in a billing system, the bill
and the action are not tied tightly together. person does [x] and
receives bill 3 days later or whatever. with micropayments, you
will have instantaneous transactions.

>If somebody could actually solve the this problem, rather 
>than merely claiming to have solved it via some mysterious
>means ("intelligent agents", et. al.), the savings would be 
>enormous even in existing businesses such as long distance and
>Internet service -- never mind all the new opportunities made
>possible by micropayments.  

wow, I think I've solved it. you can nominate me for some award
now <g>

Vlad the Imposter writes:

> >Telephone companies have found billing to be a major bottleneck.
> >By some estimates, up to 50% of the costs of a long distance call
> >are for billing, and this is on the order of a $100 billion per year
> >market worldwide.  Internet providers have been moving to a flat fee in 
> >order to minimize these costs, even though this creates the incentive for 
> >network resource overusage.  
> 
> imagine a user who controls his own wallet. he knows when he is paying
> from that wallet. you seem to have this idea that outsiders could
> make queries to that wallet that would be hard for the consumer to
> keep track of. this makes no sense to me. the wallet action will always
> be tied with some other action. the user picks up the phone to dial
> somewhere, and it says, "that will be .3c-- will you pay"? he says
> yes. 

I'm sort of a neophyte when it comes to digital cash, micropayments and
so forth but it seems to me that your example provides a fine platform
for discussing the problem.  How will you know the cost is .3c a priori?
What's to stop me from saying yes to the .3c and staying on the line
forever?  If you disallow that, how?  Will it cost the same amount if
I'm not sending anything as it will if I'm sending a live video + audio
feed?  If so, what's to stop me from bundling my whole neighborhood's
Internet traffic into this call?  If not, how will you tell the
difference without monitoring my usage and requiring me to pay for the
additional bandwidth I use?

Or are you saying that each IP packet will have an appropriately sized
digital cash payment attached?  That seems like too much overhead.
And besides, that contradicts your idea that the user would explicitly
approve each wallet access.

It gets even worse if you're an ISP, you obviously can't sit there
and approve each session that goes by (even if you could distinguish
higher level session boundaries which you won't be able to do).  Are
you just to assume at the end of the day that everything worked
perfectly and you received enough revenue to cover your costs without
knowing anything about the payment/usage profiles of any of your
customers?  And how is the ISP's network provider to know how much to
charge the ISP?


-- Jeff

-----BEGIN PGP SIGNED MESSAGE-----

Hello Jeff B, vznuri, szabo & alia.


Jeff wrote:
>
> Or are you saying that each IP packet will have an appropriately sized
> digital cash payment attached?  That seems like too much overhead.
  
  
So people who work on micropayments are trying to reduce that 
overhead.  It is clear to me that it is feasible to do so.  
(Someone have a list of references to published micropayment
schemes that I can insert here?)  IPng headers have plenty of
room for this kind of thing, don't they?
 
 
Also on this thread someone mentioned seeing an icon that says  
"5 cents" and clicking on it to pay 5 cents from their wallet.  
Well, please start your Ecash(tm) wallet and visit 
"http://www.c2.net/~bryce/BuyBAP.html".  Click on the dime.  
Better yet click on the pair of quarters.  As a bonus you 
actually get a copy of 'Bryce's Easy PGP', too!
 
 
(Sameer's the one to blame for this new threat to our national
security/children's innocence/community standards/etc.  His
"Ecash(tm) integrated with c2.net" system underlies my
cybershop.)
 
 
Regards,
 
Bryce
 
#include <stddisclamer.h> /* I'm not speaking for anyone else at this time. */
- ----- BEGIN GOODTIMES VIRUS INNOCULATION -----
Once you have read and understood this .sig, you are immune 
to the Good Times virus.  Please help spread this innoculation!
- ----- END GOODTIMES VIRUS INNOCULATION -----




-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: www.c2.net/~bryce -- 'BAP' Easy-PGP v1.1b2

iQCVAwUBMbg/mvWZSllhfG25AQGOGwP/SwDNHECjGy5a7dNVIVZEjLofN+Dgsoq0
ri7LrIE/m5hyj9Xu2HelM8o8p8e2bTylQ7GFcTZVFYBYMbb2INldFacf4X/hGfrG
snhDWuV2ZQts4/CO92hQ44OhPSCTFPHH+nKnocTQRwNOySqPWGTxSxnvFO+Grguv
NMv7U9k/do0=
=uvhj
-----END PGP SIGNATURE-----

I don't understand why this micropayment thing is being thought
so complicated.
I am making some simple assumptions that seem to not be obviously
apparent, apparently.
I don't think micropayments make sense in transactions in which
the buyer requires the ability to back out of a purchase. in
other words, if I download an FTP file, pay 2c, and then say,
"this isn't what I wanted", I don't think a refund is typically going
to be supported. it would be up to individual vendors, but I doubt
very many would allow it.

a service [x] knows how much they are going to charge for a file
or a http transfer. they tell the user, "you can have this for
[x] cost". the user *sends* them the money to get the data.
there is no concept of the company going into their wallet and
pulling out the cash. the buyer sends the token and initiates the
entire transaction. I am not saying this micropayment thing is
going to be the only way future transactions will work. of course
not. it's just one way that makes some assumptions.

what about services that don't deliver? I would imagine a cyberspatial
equivalent of the BBB will be just fine for that. an agency that
registers complaints. a company doing a micropayment bilk scheme
could only get away with a small amount of cash before they got
a bad reputation. the reputation could be checked by the browser
prior to paying, that kind of thing.

the example I gave of a phone service billing people for phone calls
was not a great example for micropayments, but it could be pulled
off. imagine that your phone has a little readout that tells you
how much you are being charged. you can cancel the call. you can
watch your little readout as it bills you money. you could set
limits, "do not pay more than 10c/minute". these limits are built
into your *local* wallet (browser, phone) etc.-- they are not
handled by the company that is charging you. hence you retain
full control.

  If you disallow that, how?  Will it cost the same amount if
>I'm not sending anything as it will if I'm sending a live video + audio
>feed?  If so, what's to stop me from bundling my whole neighborhood's
>Internet traffic into this call?  If not, how will you tell the
>difference without monitoring my usage and requiring me to pay for the
>additional bandwidth I use?

MICROPAYMENTS. they are for small transactions. the standard billing
model will be used in other situations as it is today, although it
will be moved into a cyberspatial equivalent. micropayments are NOT
going to be the only way the future economy will work. I think some
people seem to have some misconceptions about this. it won't make
sense to use microcurrency everywhere. I don't know if micropayments
will ever be tied to each pack like you are proposing. at least
in the beginning, I would assume a structure like the internet is
today with a micropayment charges built on top of it like I suggested
with browsers or that kind of thing.

companies will probably charge for bandwidth if they are charging for
network services. you can't send a lot of data without using more
bandwidth.

Yo are assuming away facts that some of us cannot assume away.

>From your message Fri, 07 Jun 96 13:58:53 -0700:
}
}>
}>> the wallet action will always
}>> be tied with some other action. the user picks up the phone to dial
}>> somewhere, and it says, "that will be .3c-- will you pay"? he says
}>> yes. 
}>
}> How will you know the cost is .3c a priori?
}>What's to stop me from saying yes to the .3c and staying on the line
}>forever?
}
}I don't understand why this micropayment thing is being thought
}so complicated.
}
}I am making some simple assumptions that seem to not be obviously
}apparent, apparently.
}

Specifically, you assume that no one will want to audit and check up
on micro-charges that accumulate nto bills.  Like my phone bill with 5
pages of 2-5 cent toll calls.  I really don't want to analyze all
that, but I also don't trust the phone company to always present me
with an accurate bill. 

So, I would rather deal with the accumulation schem by paying a fixed
fee for a service that does not send me all that deatil that I cannot
use or analyze.  To use it I would have to keep a log, with the times
of all calls to compare.

Now, you want to move this kind of charging to some service I do not
trust as much as I trust the phone company, and send me a bill for an
accumulation of charges without supporting detail.  Thsi might be OK
for small amounts, but what about a large company where these
undocumented microcharges add up to say, $200,000/year?

How do we know that someone is not simply padding the bill?  All we
need is for the billing system to slip in an occasional bogus charge
the looks for all the world like any other microcharge.

You know, like the bank employee case where someone accumulates the
round-up transaction adjustments to an account and ships the money to
Switzerland.

This is what you are omitting in your assumptions...
I just don't believe the world is going to be so trusting....\Stef

On Wed, 5 Jun 1996, Nick Szabo wrote:

> 
> Some electronic commerce projects promise dramatically lower transaction
> costs, so that we can achieve "micropayments", "microintermediation",
> and so forth.  Is this achievable?  
> 

Well let me chip in on this.  First, my Web site at
   http://www.sims.berkeley.edu/resources/infoecon/Commerce.html
has links to lots of the relevant resources.

I think that there are really two accounting models that are being
discussed.  One is centralized accounting, a la the phone company.
The other is what I call "distributed accounting".  Models for
distributed accounting are postage stamps/meters, and cash.
In the distributed accounting model, individuals get tokens
(stamps, coins, dollars, BART cards, phone cards, etc.) and keep
track of their own usage.  This form of accounting is ideally suited
to micropayments.  You may lose your BART card, or your dollars,
but that risk is borne by the user.

As Stefan pointed out, micropayments can add up in a big organization.
But in the distributed accounting case, it is the organization's 
responsibilty for managing these payments.  Indeed, most organizations
have strict policies about petty cash, postage stamps, etc for just this 
reason. 

Centralized accounting is much more open-ended.  Here the risk of 
non-payment is often partially borne by the provider and partially
by the user.  This form of payment is typically used for repeated
purchases where reputation/credit-worthiness plays a big role.

Hal Varian, Dean           voice: 510-642-9980
SIMS, 102 South Hall       fax:   510-642-5814
University of California   hal@sims.berkeley.edu
Berkeley, CA 94720-4600    http://www.sims.berkeley.edu/~hal

On Wed, 5 Jun 1996, Nick Szabo wrote:
> Consider a feature fairly independent of the particular payment system: 
> the statement of charges.  Here lies a tradeoff here between completeness 
> and complexity.   On the one hand, merely summarizing charges creates 
> the opportunity for salami frauds, allowing widely distributed false or 
> exaggerated microcharges to go undetected.  Furthermore, parties reading 
> only the summaries get no feedback by which they can adjust their behavior
> to minimize costs.  On the other hand, a statement too complex to
> be easily read also allows fraud, error, and inefficient usage to 
> go unrecognized, because one or both parties cannot understand the 
> rationale for the charges in relation to the presumed agreement on
> terms of service and payment. 

When we are faced with a complex set of interactions with which we expect 
the average person to not only be able to understand, but use, then it's 
always helpful to use metaphors.  Consider the following:


  Many people drive cars.  Those cars require gas.  Gas is "spent" in 
very small amounts at any discrete moment in time, but those who use cars 
are used to paying for gas in lump sums and not necessarily fretting 
about the state of their "gas balance" at every step of the way.  People 
who drive cars have two valuable metrics to gauge their usage of gas and 
the rate at which they spend it: the speedometer and the feul tank 
levels.  When people drive fast, their speedometer is high, and they know 
they are burning gas at a faster rate than when they drive more slowly 
(compensated by the fact that they are getting somewhere faster).  People 
are also used to refilling their gas tank when they get low.


Now, let's consider bridging this metaphor into the micropayments world.  
Imagine that surfing the web is like driving a car - you'll dribble out 
small amounts of money over a period of time, but as long as you watch 
your speedometer (the rate at which you spend money) and the feul tank 
levels (the amount of coinage in your wallet), you are in control of your 
spending rates.  Whether you approve every micropayment explicitly, or 
you set a minimum level below which requests for payments are automagically 
granted, is up to you.  Me, I'd probably be alright with just about any 
site I go to asking for less than $.02 for any action I take.  Anything 
above that, I want to be explicitly asked.  My user interface has a gas 
gauge and a speedometer in the upper-right-hand corner instead of a 
throbbing "N".  When my levels are low, I go visit my bank and "refill" 
my wallet.  Voila!

The billing happens, as others have previously noted, entirely at the 
client side.  There's no reason the wallet or web browser can't keep a 
log of expenditures, and there's no chance for spoofery at that point 
(the wallet knows where it sent money).  

And yes, I am presuming a system involving transfers of digitally signed 
tokens of some sort.  I don't think this is a mistaken presumption.  

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  |  We're hiring!  http://www.organic.com/Home/Info/Jobs/

Your analogy breaks because you do not provide for the corresponding
of connections between the gas tank and the dashboard indicator for
the case of buying small items from many different vendors.

I can see each vendor site giving you a "gas gauge" indicator, either
showing how much you have cumulatively charged at a given site, or how
much is left on your prepaid site account (these are the same thing in
terms of adding up charges), but I fail to see how your analog applies
outside the local control of each vendor site.

In short, you have again shown that microcharging systems are limited
to local accumulations.  Your gas tank example is limited to the car
you are driving, and does not tell you anything about anything else.

Unfortunately, you appear to be applying the idea to a collection of
vendors which you wish to visit, which means that someone somewhere
must be getting the disparate charges from different vendors to update
your singular gas gauge.

Drawing analogies is great fun, but all analogies break at some point
in their life, because they abstract away enough detail to paint a
simplified picture.  Sometime this leads to complete failure to map as
intended.

Best...\Stef

>From Brian Behlendorf's message Mon, 10 Jun 1996 21:49:05 -0700 (PDT):
}
[snip]....
}
}Now, let's consider bridging this metaphor into the micropayments world.  
}Imagine that surfing the web is like driving a car - you'll dribble out 
}small amounts of money over a period of time, but as long as you watch 
}your speedometer (the rate at which you spend money) and the fuel tank 
}levels (the amount of coinage in your wallet), you are in control of your 
}spending rates.  Whether you approve every micropayment explicitly, or 
}you set a minimum level below which requests for payments are automagically 
}granted, is up to you.  Me, I'd probably be alright with just about any 
}site I go to asking for less than $.02 for any action I take.  Anything 
}above that, I want to be explicitly asked.  My user interface has a gas 
}gauge and a speedometer in the upper-right-hand corner instead of a 
}throbbing "N".  When my levels are low, I go visit my bank and "refill" 
}my wallet.  Voila!
}
}The billing happens, as others have previously noted, entirely at the 
}client side.  There's no reason the wallet or web browser can't keep a 
}log of expenditures, and there's no chance for spoofery at that point 
}(the wallet knows where it sent money).  
}
}And yes, I am presuming a system involving transfers of digitally signed 
}tokens of some sort.  I don't think this is a mistaken presumption.  
}
}	Brian
}
}--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
}brian@organic.com  |  We're hiring!  http://www.organic.com/Home/Info/Jobs/
}

more dazed and confused responses on microcurrency... why are people
making this so complicated???

From: Einar Stefferud <Stef@nma.com>
>
>Your analogy breaks because you do not provide for the corresponding
>of connections between the gas tank and the dashboard indicator for
>the case of buying small items from many different vendors.
>
>I can see each vendor site giving you a "gas gauge" indicator, either
>showing how much you have cumulatively charged at a given site, or how
>much is left on your prepaid site account (these are the same thing in
>terms of adding up charges), but I fail to see how your analog applies
>outside the local control of each vendor site.

the *vendor* *does*not* control the "gas gauge". the gauge is presented
by your LOCAL SOFTWARE. (for those late into this, the gas gauge analogy
is used as a visual metaphor for the way a browser would keep track
of microcharges).  it would make *no*sense* for each provider to
create their own gauge. they might create one for their own site
of your transactions, but you absolutely must have a tracking mechanism
that is built into your own software and NOT under the control of the
outside agency. 

don't people get this? with microcurrency, you don't say to a 
seller, "bill me for this item". it would rarely work like that at
all. instead, it is, "here is my money, please give me the item". 
the money exchange is always part of the complete transaction. 
billing is an archaic concept in this paradigm that is superfluous.
you only need it when you can't have instantaneous transactions.

>In short, you have again shown that microcharging systems are limited
>to local accumulations.  Your gas tank example is limited to the car
>you are driving, and does not tell you anything about anything else.

the gas gauge analogy seemed transparently obvious to me. 
you are proving a rule I've noted in cyberspace, that if anything
can be misunderstood, it will be.  you are confusing yourself. 

the analogy would be more like the
following: you can drive on different roads, and some take more
gas than others. but the roads cannot themselves suck gas
out of your tank or change your gas meter.

>Unfortunately, you appear to be applying the idea to a collection of
>vendors which you wish to visit, which means that someone somewhere
>must be getting the disparate charges from different vendors to update
>your singular gas gauge.

NO, NO, NO!!!! your local software controls your gas gauge. NOBODY
ELSE. furthermore, the site *never* grabs money from you. this is
a *billing* paradigm. you either send money, or no money can
be transferred. the site can *request* money but such a system
would only be automatic if the charge fell within the minimal limits
set by the user (i.e. max $1.00 per hour, max 5c per transaction,
max 10 transactions per minute, or whatever--  all this is 
trivial to implement)

>Drawing analogies is great fun, but all analogies break at some point
>in their life, because they abstract away enough detail to paint a
>simplified picture.  Sometime this leads to complete failure to map as
>intended.

analogies are meant to help people understand something simple. if the
thing itself is simple, and people can't even understand it in
the simple state, often the analogy will confuse them even further.

>}The billing happens, as others have previously noted, entirely at the 
>}client side.  There's no reason the wallet or web browser can't keep a 
>}log of expenditures, and there's no chance for spoofery at that point 
>}(the wallet knows where it sent money).  

I wish people would stop talking about BILLING in regard to microcurrency.
I believe it is mostly a flawed concept that is not largely going to
apply to microcurrency. perhaps some other term is appropriate, any
takers? it seems to me a lot of the misconceptions I've been seeing
are based on the idea that BILLING would somehow be involved. 
billing is involved in cash systems in which you dissociate the
transfer of material from the transaction. this will generally
not happen with microcurrency imho, and it is largely only useful
with transactions that allow coupling of the material and the money
in one swipe, such as for a http file download or whatever.

On Jun 20, 12:05, Vladimir Z. Nuri wrote:
> Subject: Re: Micropayments: myth?

[ snip ]

>don't people get this? with microcurrency, you don't say to a 
>seller, "bill me for this item". it would rarely work like that at
>all. instead, it is, "here is my money, please give me the item". 

What is the authentication process for the "money" your are "giving" in this 
scenario?

Cheers!
[ psr ]

Hmmm,,, In general, when someone says something this is misunderstood,
it is upon the speaker to make it understandable, though it of course
helps if the listener is trying to understand.

Shall we continue to argue about which of us are being responsible
speakers/listeners, or disucuss the subject at hand.

I fear that I did not see in yoru text any mention of requiring the
transfer of microcurency during the transaction.  Yes, of course, if
you solve the microcurrency problem, so that I am actually
transferring value while my "gas gauge" is measuring the flow.

But, without a solution to the microcurrency problem, you are speaking
in entirely hypothetical terms.  

This started as a discussion of micro-charging and micro-payment, and
now is a discussion of micro-currency, ala eCash.  As such, I have
nothing to contribute;-).,..

I somehow missed the conversion signals;-)...Cheers...\Stef

>From your message Thu, 20 Jun 96 12:05:55 -0700:
}
}
}more dazed and confused responses on microcurrency... why are people
}making this so complicated???
}
}From: Einar Stefferud <Stef@nma.com>
}>
}>Your analogy breaks because you do not provide for the corresponding
}>of connections between the gas tank and the dashboard indicator for
}>the case of buying small items from many different vendors.
}>
}>I can see each vendor site giving you a "gas gauge" indicator, either
}>showing how much you have cumulatively charged at a given site, or how
}>much is left on your prepaid site account (these are the same thing in
}>terms of adding up charges), but I fail to see how your analog applies
}>outside the local control of each vendor site.
}
}the *vendor* *does*not* control the "gas gauge". the gauge is presented
}by your LOCAL SOFTWARE. (for those late into this, the gas gauge analogy
}is used as a visual metaphor for the way a browser would keep track
}of microcharges).  it would make *no*sense* for each provider to
}create their own gauge. they might create one for their own site
}of your transactions, but you absolutely must have a tracking mechanism
}that is built into your own software and NOT under the control of the
}outside agency. 
}
}don't people get this? with microcurrency, you don't say to a 
}seller, "bill me for this item". it would rarely work like that at
}all. instead, it is, "here is my money, please give me the item". 
}the money exchange is always part of the complete transaction. 
}billing is an archaic concept in this paradigm that is superfluous.
}you only need it when you can't have instantaneous transactions.
}
}>In short, you have again shown that microcharging systems are limited
}>to local accumulations.  Your gas tank example is limited to the car
}>you are driving, and does not tell you anything about anything else.
}
}the gas gauge analogy seemed transparently obvious to me. 
}you are proving a rule I've noted in cyberspace, that if anything
}can be misunderstood, it will be.  you are confusing yourself. 
}
}the analogy would be more like the
}following: you can drive on different roads, and some take more
}gas than others. but the roads cannot themselves suck gas
}out of your tank or change your gas meter.
}
}>Unfortunately, you appear to be applying the idea to a collection of
}>vendors which you wish to visit, which means that someone somewhere
}>must be getting the disparate charges from different vendors to update
}>your singular gas gauge.
}
}NO, NO, NO!!!! your local software controls your gas gauge. NOBODY
}ELSE. furthermore, the site *never* grabs money from you. this is
}a *billing* paradigm. you either send money, or no money can
}be transferred. the site can *request* money but such a system
}would only be automatic if the charge fell within the minimal limits
}set by the user (i.e. max $1.00 per hour, max 5c per transaction,
}max 10 transactions per minute, or whatever--  all this is 
}trivial to implement)
}
}>Drawing analogies is great fun, but all analogies break at some point
}>in their life, because they abstract away enough detail to paint a
}>simplified picture.  Sometime this leads to complete failure to map as
}>intended.
}
}analogies are meant to help people understand something simple. if the
}thing itself is simple, and people can't even understand it in
}the simple state, often the analogy will confuse them even further.
}
}>}The billing happens, as others have previously noted, entirely at the 
}>}client side.  There's no reason the wallet or web browser can't keep a 
}>}log of expenditures, and there's no chance for spoofery at that point 
}>}(the wallet knows where it sent money).  
}
}I wish people would stop talking about BILLING in regard to microcurrency.
}I believe it is mostly a flawed concept that is not largely going to
}apply to microcurrency. perhaps some other term is appropriate, any
}takers? it seems to me a lot of the misconceptions I've been seeing
}are based on the idea that BILLING would somehow be involved. 
}billing is involved in cash systems in which you dissociate the
}transfer of material from the transaction. this will generally
}not happen with microcurrency imho, and it is largely only useful
}with transactions that allow coupling of the material and the money
}in one swipe, such as for a http file download or whatever.
}

a brief epistle as to the point as I can make it:

there are two money models that people are continuously conflating here:

1. I send money to someone who is selling something. they send me
that something. by definition, no billing was involved here.

2. I send a request to someone who is selling something. they send
me the something, along with a bill, which I have to pay, or possibly
decide not to. (the thing may arrive before or after the bill, 
wehther I pay, etc)

(2) is a whole class of systems in existence today, such as your cable
bill, your phone bill, etc.  much of these systems *might* be 
better implemented as (1) if/when (1) becomes available. (example,
your tv is charged micromoney, etc). but not *all* of them will be. 
(example: maybe phone companies prefer to accumulate chages and bill
at end of month. also, major "float" issues are often involved
here, although in that case not in their favor. "float" theoretically
evaporates with microcurrency)

regarding (2), it would be *possible* to have a billing system
that involved microcharges, but frankly I don't think this will
be very feasible or a wide use of the system. (1) and microcurrency
go together. (2) and microcurrency do not. is this fairly apparent
or should I give more examples?

lets say I consider hitting a web page that has a "rate" of 2c. I would not
call that a "bill". I haven't hit the page yet or requested a service.
but when I hit the page, the page says, "send me 2c". I would not 
call that a bill so much either in the classic sense-- it would be
like saying a cashier bills you when you hand them cash. well, yes,
in a strange way I guess but not really.

note that (1) presupposes that you actually have a cash type system.
systems such as credit cards whereby the payment is not necessarily
ensured, stuff like defaulting or rejecting a purchase etc. don't
fit in too well with microcurrency, in which we are talking about cash.

> [...] "float" theoretically
> evaporates with microcurrency)

Ah, hmmm? How do you buy your microcurrency? Who has the float while you
have cyberbucks on your disk.  The float doesn't evaporate. It just goes
different places.

--
 Darren New / Dir. of Custom Software Design / First Virtual Holdings Inc.
  http://www.fv.com or info@fv.com  -=|=-  PGP Key: ftp://ftp.fv.com/pub/fv

A general limitation of level and rate gauges is that they apply
only to fungible commodities.  One gallon of gas is roughly as
good as any other, and one dollar is as good as any other(*),
so that the a gas pump gauge reflects the information important to the 
gas buyer.  Where variety in quality or features is important, or 
different products and services need to be purchased, the graphical
display of levels and rates does not reflect that information.

For this reason, most Internet commerce purchases are made by filling
out forms, the user selecting various features to be included in the
shipped product.  Such information cannot be reflected in a gauge,
and interaction by filling out forms is far too expensive for
micropayment transactions.  Incomparable transactions lumped
into a summary lose important information, while mathematically
comparable transactions so summarized do not (as long as the
summary display properly reflects the mathematical relationship).
Incomparable purchases must be looked at separately to
determine whether one was charged a fair rate, or whether the
transaction will be or was desirable.

There are some potentially fungible Internet commodities: bandwidth,
disk space, CPU time, memory, etc.  Such transactions can be summarized
losslessly, and comparability also facilitates agents automation,
so these areas provide a potential niche for micropayments.  However,
before such commodities can be traded they must be somehow be unbundled
from each other and related factors which may (availability, 
response time) or may not (human support) themselves be fungible.
Keeping track of a wide variety of unbundled services is itself
a big transaction cost.

Nick Szabo
szabo@netcom.com
http://www.best.com/~szabo/

(*) In general, currencies are linearly comparable via exchange
rates, so that currency exchange can be accurately summarized via 
gauges.  More sophisticated financial transactions require more
sophisticated interfaces.  Many of these relationships can 
in principal still be graphed continuously and even monotonically, 
but there are a wide variety of such relationships, so our work 
is cut out for us here.

As far as I'm concerned Micropayments as appealing to me as Data Mining.  I
certainly see how my wallet would benefits from being on the receiving end of
the money and/or information, but I can also clearly see the detrements of
being the one whose money and information was "automagically" being
appropriated. The technical concerns are many, any secure system can be
broken by someone with enough skill and resources, but the social concerns are
more difficult to address. For example, it's great if the browser logs
client side transactions that can't be spoofed because the wallet knows where
it sent money, but try convincing a vendor who is already suspicious of
'all this computer stuff' that you really sent them some money and a savvy
hacker pilfered it all - log or no log.

Setting a micropayment enabled web browser to automatically grant approval to
payments of $.02/action may seem reasonable, but it depends on what the vendor
has decided constitues an action.  If somone charged $.02/nanosecond for
retreiving shareware from an FTP library, and my browser was set to accept this
as reasonable based on the fact that it was $.02/action, I would have no idea
what an exhorbitant rate I was paying for access until my 'wallet' was emptied
by downloading the README file... this kind of rate swindling already goes on
in the telephone industry and would be even easier on a system like the
internet
where people habitually connect with unknown parties to check out the
offerings.
This doesn't happen with phones (well, not as much).  The virtual nomadness of
wandering the net leaves a lot of people - even otherwise careful people -
vulnerable to rate traps.

Micropayment proponents are incredibly fond of the proposition that software
could be leased on a usage time basis from a centralized server, and people
could also rent time on the servers' CPUs.  Sounds an awful lot like the
mainframe days to me.  I see plenty of ways in which this benefits the
vendor
(greater control over distribution, centrailzed revision/upgrade distribution,
greater profits over one-time sales, etc.), but no ways in which this benefits
the user.  Especially the power user.  I'm certainly not going to rent time
on a compiler or image editing program every single time I want to do some
work.
It took the industry long enough to get PCs and workstations to the speeds
they're at today so people could do their own work on their own machines to
go back to waiting in a queue for time on a centralized system so you can
have the honor of paying someone a lot of money to run your job.  As a
programmer, I can
see how I could make a fat chunk of change by bilking people through metered
software usage, but as a software consumer it seems like a rotten idea.  One
effect it would have, however, would be an exponential increase in the quality
and quantity of software available from the Free Software Foundation and
other similar groups as people like myself fled en-masse from commercial
software to a
system where we knew what we were getting into ahead of time.

The other rotten part of this idea, of course, is the irritating lag times
involved with trying to run distributed software (especially poorly
distributed
software, and especially on an overloaded network infrastructure).

Looking at micropayments from the (economically) conservative element
viewpoint within certain industries make them seem a lot less appealing, as
well.  Take television.  If people had to purchase every TV show they
watched, there would be a lot less TV production going on because there
wouldn't be as much random TV watching.   No matter how stupid you may
think your customers are, if you change their pay structure they think
about it - even if only briefly.  It would also be harder to sell TV
advertising, because if nobody was watching a show everyone would know
because this would be metered even better than current rating systems.  The
nature of the TV advertising industry would change because instead of the
archetypal/statistical sampling of Nielsen ratings, you'd know *exactly*
who was watching what.

Both micropayments and data mining require that the user give the vendor a
level of trust which most vendors are not willing to repay with similar
trust and customer satisfaction.  Customer-users are expected to give
vendors greater access to and control over their money and personal
information, yet at best they can expect the same poor customer service and
bureaucratic attitudes encountered when dealing with traditional
transaction processing companies and at worst can expect to be swindled out
of piles of money and/or have their
privacy violated as a matter of course.

Working where I do, everyone around me is on the side of the vendors - who
make up part of our client base.  On cypherpunks, of course, I'm largely
preaching to the converted.  There can be a middle ground, however the
middle ground that's been offered so far still leaves the consumer with the
sort end of the stick and
I'm not convinced they're ultimately what's best for business - especially if
you cling to seemingly outdated ideas like good customer relations, good
public/social relations, and long range growth relationships over short
term
profit pumping.


ttl
Stephan

-------------------------------------------------------------------
This signature has been kidnapped by space aliens.
If you find it you can call (415) 703-8748.
I work for Studio Archetype, and they don't find any of this funny.

>... how much data
>mining is starting to catch on and the positive, quantifiable
>returns it is generating.
>
Returns for whom?

>can people "automagically" take money from your ATM card? nope. in the
>same way, your microwallet will be secure. it will be even more secure,
>because less money is involved.
>
How much money is involved would be up to the consumer.  It would be as secure
as a normal wallet, excepting that I don't usually give people permission to
open my wallet and take money out at regular intervals.

[...]
>can ensure that the money is transferred. the data is not delivered
>unless the payment is received. scam artists can be caught with
>"better business bureau" type rating services.
>
Any cryptographic system has ways to circumvent it.  Whether or not they
are practical is the issue.
As for scam artists, perhaps we could have a scam-artist bit along with
the age bit ;)

>the poster clearly suggested payment PER TIME as a limit.  a pretty
>obvious concept, and easy to implement, don't you think? why does it
>figure as one of your major objections?
>
Because the time limit can be set ridiculously low, making the rates
artificially high from the viewpoint of the kind of time periods that
humans work in.

>it won't happen with micropayments either, because it will be *your*wallet*
>that tells you when it is has an opportunity to pay. no one is dipping
>into your wallet, metaphorically. the actions are always initiated by you.
>
The action of going somewhere that charges a metered rate is initiated by the
user, however to make this safe for the consumer it would have to be required
that there be a 'front door' for every site that charged metered rates
announcing that if you proceed you'll be billed (and, at what rate).  If you
let people charge as soon as you hit their URL, that's malarkey.

>somewhat. mainframes aren't totally the mark of the devil. don't you pay
>your internet provider per hour? how many people do? isn't a Sun pretty
>
No, I don't.  I use it too much, so I found an ISP that does not charge metered
rates.  A lot of people pay by the hour for their ISP, but it may or may not
be a wise idea for them.  If it's part of their work and they're online all the
time, they should consider another payment system.  Same thing with charging
micropayments for using software.  If Adobe started charging me $5/hr to use
Photoshop instead of $500 for the package, I'd stop using photoshop.  In two
weeks I'd have already exceeded the price of the whole package.

>much equivalent/similar in processing power & capability to old mainframes?
>you raise all kinds of objections that make no sense to me.
>
Sure it's the same power as an old mainframe.  Big deal.  What exactly does
that
do to stregnthen your argument?  It's certainly not as costly to build, costly
to maintain, or rare as old mainframes...

>the user is always free to go where a better vendor gives him what he
>wants. because the user can now pay in tiny increments, he has enormous
>increase freedom. he can move between different services far more readily.
>no body is FORCING anyone to spend money.
>
The potential for scams exists.  Certainly even a priest in the church of the
free market can see that.  User education is poor, and consumer protection laws
are weakening.  This does not bode well fo r

>uh huh. what if over your lifetime it cost far less than you pay for
>a shinkwrapped package?
>
If that happened, I'd be very suprised.

>what if you only needed a quick compilation on
>a system you don't normally use? I think you will begin to figure out
>some advantages if you use your imagination to find them (instead of the
>drawbacks)
>
That is a good advantage, you are correct in this.  But there are a number of
instances in which I'd still want software running on a real workstation.  If
people make software only available through micropayments, then that would be
limiting to both the user and the vendor.

>you have this concept of "automated billing" that simply doesn't fit. people
>know how much they are being charged. the payment is UNDER THE COMPLETE
>CONTROL OF THE PAYER, NOT THE BILLER. this simple misconception seems to
>underly a lot of the micropayment objections I've been seeing.
>
The payer could set a certain amount of money that is automatically deemed
acceptable to pay, like the $.02/time-unit example.  This could get misused
by a vendor who chooses a unit small enough that a small per-unit charge
quickly
adds up.  The payer essentially loses control of payment.

>or, it may be that entire new industries spring up because the software
>companies are better able to be compensated for their work from skittish
>consumers. people may be more free about spending micropayments than
>buying shrinkwrapped software. psychologically I think micropayments
>are far more appealing in some ways.
>
In some ways.  But those of use who use certain packages heavily would get
shafted for our loyal support of a vendor if they decided to pander to the
skittish masses and charge a rate that was psychologically more appealing
to
those who wouldn't otherwise use it.  I only hope that vendors who choose to
use micropayments (since they're inevitable) take the small but loyal power
user segment into consideration when making the decision about whether or not
to stop selling full packages altogether.

>admittedly some things have to be in place: a high speed network, and
>other infrastructure ideas. it isn't totally feasible today in cyberspace,
>but large parts of it are and are already being implemented (chaum's
>digicash)
>
The best model is not the mainframe model promoted by the idea of the "internet
computer" (aka. Mutant X-Terminal), but a truly distributed system.
Workstations and PCs can contribute their substantial processing power to a
distributed system.  The other problem I have with the mainframe model and
centralized resources is storage.  It's bad enough to have to wait in line for
a CPU, but the idea of having no direct access to my work is unappealing,
and for a number of industries impossible.  I doubt designers, for example,
would
be willing to leave client work on the big Illustrator server cluster at Adobe.
Fat pipes connecting fast PCs to even faster servers is the best route.


>false, imho. imagine that I can buy only the shows I want to watch, and it
>>out to less than my $20 monthly cable bill. economically this is perfectly
>sensible. people want to pay for what they watch. you seem to think that
>
I was looking at this from a vendor viewpoint in this particular instance.  The
TV old guard may not be willing to give up all that big, fat (and reliable) ad
revenue to the whim of John and Jane Q. Tvwatcher.

>micropayments means "everything costs more". a strange assumption. what if
>I assume, "everything costs less" because billing costs, which other
>posters have pointed out are so enormous, are vaporized?
>
I'd like to see them vaporized.  Billing costs are the swindle of the decade.
I'm quite tempted to cut up both my credit card and ATM card because of the
bullshit administrative fees involved with using them.  Internet transaction
fees are even worse.

>it is true that some industries will change and meld into other forms
>with this new revolutionary form of payment.  welcome to the concept of
> an economy in which anything that is stagnant tends to die.
>
Yeah, but the old tends to cling on for dear life.  Welcome to the concept
of people and institutions that are unwilling to change and do their best to
postpone those changes.

Change doesn't bother *me* personally, I just wish more people would *think*
about whether or not changes are *appropriate* instead of just *possible*.

>right. shows that are not watched are going to go extinct. why should
>advertisers fund them? you think that advertisers have to be fooled
>to pay money to a show?
>
They are now.  It was a pragmatic point.

>that's correct. why do you suggest it would be an infeasible apocalypse?
>it might be an apocalypse of old concepts, but it isn't infeasible.
>
That's not infeasable.  I didn't say anything was infeasable, I just think
some of the current models of how things might work are bad ideas and encourage
debate.  Both consumers and resistant old-school vendors will have issues to
address, and ramming change down people's throats because it's inevitable or
'the market dictates it' is a crappy attitude which I don't encourage.  Also,
note for the record that I don't believe that "the market" is a one-to-one
mapping on to "the people" or even "the consumer".

>false, imho. again the consumer maintains complete control. in a sense
>they have far greater control. if they don't like a company they
>can go somewhere else after only spending a micropayment instead of
>a macropayment. you may find that companies increase their level of
>service and customer satisfaction. but there will probably bogus uses
>that apparently you will gravitate towards, based on your seeming
>preference for them.
>
Ha ha ha.  Yeah, looking out for consumer interests is just doom saying and
negativism.  The current education level of the general public about computers
is low, and about transactional security is even lower.  It can have benefits,
but there are also serious issues which need to be considered.  Another thing
about the paying a micropayment instead of a macropayment and leaving if
you don't like it - a lot of companies offer free trial time with their
service, or a free consultation, etc.  The effects of charging for these
trial offers is
unclear - how would that be good for the consumer?

>imagine shareware authors getting cash for their programs based on their
>actual use. imagine artists and writers bypassing corporate monoliths
>and marketing their work to the public directly, bypassing the enormous
>scrape-off that these self-perpetuating bureacracies snarf.
>
This is a good idea.  It could be a good boon for small businesses (unless
the transaction providers charge prohibitively large fees for their
services...).  I hope you're right and I'm wrong.  That would be much better
for all involved.

>you seem to start from the assumption, "businesses are out to shaft the
>little guy". well, that can be true whether you have micropayments
>or not. I doubt micropayments would make it any worse. it won't solve
>the problem (I agree there is a great greed in places) but it may actually
>make it far more difficult for companies to shaft people, once you think
>about it. remember, the consumer has total control. how can you get
>shafted when you have total control?
>
Your argument works provided the consumer really maintains control.
You can lose that control.  There do need to be safeguards in such a system
that ensure this control.  $.02/nanosecond is, after all, $1.2 billion/minute.
If such a setting were allowed and people habitually allowed $.02/unit
metering as being automatically acceptable, that could clean out a number
of digital
wallets very quickly as unsuspecting customers entered the paid area and
instantly got dialogue boxes announcing that their wallets were empty.

ttl
Stephan


-------------------------------------------------------------------
This signature has been kidnapped by space aliens.
If you find it you can call (415) 703-8748.
I work for Studio Archetype, and they don't find any of this funny.

it seems to me many of mr. Bugaj's complaints refer to the
deficiencies of a capitalist market, such as scams, greedy
companies, etc. he seems to think micropayments may exacerabate
this problem. in any case I agree there are problems with
capitalism, but I think micropayments may have the effect
of ameliorating some of the deficiencies. 

today we have payment systems that are "blocky" or have
"large granularity". many companies function as billing
services. in other words, they sell some product, and would
rather not get into the payment collection business, but the
economics of scale forces them to. the phone company is
forced to send out mail and have a zillion clerks to handle
the returned bills. the country is awash in checks and 
paperwork. I can easily make a good case that micropayments
may have a significant dent in this paradigm such that
companies can focus more on providing services than collecting
cash. the dividends would be obvious and enormous.


I'll skip most responses and focus on a few in particular..

>>somewhat. mainframes aren't totally the mark of the devil. don't you pay
>>your internet provider per hour? how many people do? isn't a Sun pretty
>>
>No, I don't.  I use it too much, so I found an ISP that does not charge metered
>rates.  A lot of people pay by the hour for their ISP, but it may or may not
>be a wise idea for them.  If it's part of their work and they're online all the
>time, they should consider another payment system.  Same thing with charging
>micropayments for using software.  If Adobe started charging me $5/hr to use
>Photoshop instead of $500 for the package, I'd stop using photoshop.  In two
>weeks I'd have already exceeded the price of the whole package.

again, you are making arbitrary assumptions. the figures you cite
are "straw men". OF COURSE micrompayments make no sense if you end
up spending more money. I totally agree with you there, who could
argue? all the micropayment proponents are starting from the
assumption that services you now pay for could be cheaper given
the micropayment model. you seem to think that micropayments mean,
"companies have more opportunity to shaft you". but equally perhaps,
it is more opportunity for the consumer to exercise control with
less at stake.

>
>>much equivalent/similar in processing power & capability to old mainframes?
>>you raise all kinds of objections that make no sense to me.
>>
>Sure it's the same power as an old mainframe.  Big deal.  What exactly does
>that
>do to stregnthen your argument?  It's certainly not as costly to build, costly
>to maintain, or rare as old mainframes...

alright, your mainframe idea is way off for several reasons. first, the
mainframe is not dead, it has just been transformed into Sun and Unix
boxes all over the planet. so even if a system was "like a mainframe",
I wouldn't consider that the mark of the beast as you suggest. furthermore,
mainframes are about CENTRALIZATION. imagine a single computer like
Prodigy that was the bottleneck through which you got all your software
over the net. ok, that would be horrible. it would also be like the
mainframe concept you are criticizing.

but micropayments are not about centralization, they are about 
DISTRIBUTION. imagine a zillion software providers all over the planet.
each can meter you out software at a tiny fee per time. this is 
clearly not like a centralized mainframe situation at all, assuming you can get
similar software from a zillion different places.  it *is* similar
in that you are grabbing cpu cycles from outside your computer, but
this is arguable just a network. mainframes used networks too. does
that make networks evil? no, I don't think so!! surely you are in
favor of networks!!

>>uh huh. what if over your lifetime it cost far less than you pay for
>>a shinkwrapped package?
>>
>If that happened, I'd be very suprised.

that's the kind of savings people who promote micropayments are betting
on. again, I agree that if the consumer ends up paying more in some
way with micropayments, they're doomed to never get off the ground.

>That is a good advantage, you are correct in this.  But there are a number of
>instances in which I'd still want software running on a real workstation.  If
>people make software only available through micropayments, then that would be
>limiting to both the user and the vendor.

as I wrote, I don't believe micropayments are going to be the only
form of transaction in the future. surely nobody else is advocating this
either.

>In some ways.  But those of use who use certain packages heavily would get
>shafted for our loyal support of a vendor if they decided to pander to the
>skittish masses and charge a rate that was psychologically more appealing
>to
>those who wouldn't otherwise use it.  I only hope that vendors who choose to
>use micropayments (since they're inevitable) take the small but loyal power
>user segment into consideration when making the decision about whether or not
>to stop selling full packages altogether.

I imagine that people will have a wide variety of ways to use the software
they want to use. every company that sells software has a lot of plans
right now. I'm sure that micropayments would only be one other way
for the consumer to pay for what he uses. they may become preferrable
in some cases where both the company and consumer agree they are 
benefitting. but companies that shaft their customers, which you seem
to be preoccupied with, imho ultimately go the way of the dodo bird.

>The best model is not the mainframe model promoted by the idea of the "internet
>computer" (aka. Mutant X-Terminal), but a truly distributed system.
>Workstations and PCs can contribute their substantial processing power to a
>distributed system.  The other problem I have with the mainframe model and
>centralized resources is storage.  It's bad enough to have to wait in line for
>a CPU, but the idea of having no direct access to my work is unappealing,
>and for a number of industries impossible.  I doubt designers, for example,
>would
>be willing to leave client work on the big Illustrator server cluster at Adobe.
>Fat pipes connecting fast PCs to even faster servers is the best route.

notice that if you have a zillion mainframes all over the planet, each
one that can serve you, the idea of a mainframe is not all that bad.
what you are really opposing is *bottlenecks*, such as a zillion
people needing one mainframe. I agree the system
must be carefully designed to avoid them.

>>
>I was looking at this from a vendor viewpoint in this particular instance.  The
>TV old guard may not be willing to give up all that big, fat (and reliable) ad
>revenue to the whim of John and Jane Q. Tvwatcher.

neither was the catholic church willing to give up their monopoly
on bible interpretation when the printing press was invented. my
comment is, "yeah, so what?" or perhaps "now you GET IT!! hee, hee"

>Yeah, but the old tends to cling on for dear life.  Welcome to the concept
>of people and institutions that are unwilling to change and do their best to
>postpone those changes.

it will happen, I agree. that's why reality can be so entertaining.
once certain people recognize what micropayments really imply, they
will be aghast like the scientologists are right now. really, I
predict that when you combine all the following:

1. micropayments
2. web technology
3. distributed computing

in a fully seamless and refined way, you are going to have an
entirely new economic system. it will come close to the realization
of Toffler's 3rd wave "information economy". I mean literally, our
economy will be tied in and tightly coupled with cyberspace. when
you put all this together it will make the current web revolution
look like bland corn flakes in comparison.

>That's not infeasable.  I didn't say anything was infeasable, I just think
>some of the current models of how things might work are bad ideas and encourage
>debate.  Both consumers and resistant old-school vendors will have issues to
>address, and ramming change down people's throats because it's inevitable or
>'the market dictates it' is a crappy attitude which I don't encourage. 

an oxymoron. by my definition, "ramming something down someone's throat"
implies the market is opposing it, or at least not openly encouraging it.
I'm all for not ramming anything down anyone's throat. I've been
advocating consumer choice. it won't catch on unless it really is better
than what we have now. it won't solve all problems, but it will
solve some.

your message contains a lot of FUD that is associated with any new
technology. once people play with it, they don't get so upset. there
was a lot of anxiety about the "information superhighway" for a long
time among people I knew. but then they discovered they could surf
the whole internet by just clicking a mouse. wheeeee!! if the
insanely neurotic "cathy" in the comic strips can handle the internet,
then *anyone* can. <g>

There is too much traffic on the Cypherpunks list for me - personally - to be
able to follow a single discussion very consistantly (maybe I should write
better filters...).  So I will address your last email generally.  I agree
that many of my points are points about capitalism in general, but
micropayments are the latest capitalist craze and serves to  underscore
some of these problems.  Perhaps you are right that they can ameliorate
some of the problems of capitalism, but I think there is also a great
potential for abuse and profit bloating that will serve only to exascerbate
the problems.  Sometimes 'straw men' are needed to make example cases of
what *can* happen before people leap ahead without thinking, and can only
in retrospect commiserate with eachother about what did happen...  the FUD
that is associated with any new technology should be better analyzed by the
few who care about the future rather than those who just worship the future
to ensure that the decisions which are made by this almighty 'market'
(again, I distinguish this from either the 'people' or the 'consumers') are
the right ones.  Again, I realize the market does not oppose this idea, but
that doesn't mean that some people won't feel that the idea is being
'rammed down their throats'.  Sometimes people forget that technologists
and their venture capitalist backers aren't the best representative sample
of the world's population, nor are they a reliable source of objective
information about the correlation between the 'market' and the 'polit'.

Micropayments might be a great idea (though I see potential flaws which, if
addressed, would only serve to make the idea great in implementation as
well as in theory - yet people will resist addressing these potential flaws
and rely on hindsight to fix problems that do arise). I'm just proposing
the ridiculous notion that this and other technologies be preceeded by
forthought and public debate before their implementation.  No matter how
much one reifies techology, it all comes back to people in the end.


ttl
Stephan


-------------------------------------------------------------------
This signature has been kidnapped by space aliens.
If you find it you can call (415) 703-8748.
I work for Studio Archetype, and they don't find any of this funny.

Mr. Bugaj makes some very good points about micropayments
being a current capitalist fad etc, and I think his idea
that venture capitalists do not necessarily exactly represent
the interests of the population is interesting.
his general message seems to be "lets look before we leap".

I tend to agree that abuses of micropayments will be possible
and one of the difficult hurdles for the system to overcome.
I don't know how pathological or difficult they will be. 
intuitively it seems like they will be less severe than
existing problems that have largely already been solved
by bank technologies. however it is quite possible (perhaps
even probable) that entirely new problems are going to
arise with the introduction of micropaymens.

so I wonder if people have ideas on some of the key problems
that might arise with micropayments. it would be very useful
to try to "head them off at the pass" and imagine what the
implications of micropayments are going to be.

here are two main problems I see right off the bat:

1. taxation. I suspect once the digital economy begins to 
get off the ground, the government is going to want to tax
it, and in a way that is enforced technologically. I wouldn't
be surprised if there are future proposals for "clipper like"
technology that integrates taxation mechanisms right into
the billing networks, mandatorily-- i.e. it is not up to the
person to report it; they simply can't escape the reporting. 

 furthermore when people
begin to realize that "anyone" can effectively "create" cash,
I expect to witness a lot of legislative panic ala today's
pornography or whatever. (digital pornography is going to be extremely
trivial in social implications compared to the ramifications of
digital cash).

the taxation problem is a part of a much larger problem: that
of good government. could it be that microcurrency will affect
our government? I think so. cyberspace has already begun to
have discernable and palpable effects on government. and it
is only beginning.  so what I would like to say is that if we
solved the problem of having a good government, issues like
taxation would take care of themselves.

2. copyrights. the issue of copyrights is not even resolved today.
when serious cash starts to be associated with cyberspace you
are going to see a lot of incredibly agitated people, especially
lawyers. I imagine systems will evolve that are similar to 
a technology that has evolved by which radio stations pay music
companies whenever they play artists songs. (if any cpunks could
elaborate on this system, I think it is an excellent preliminary
example of how a microcurrency-like system would interact with
a copyright situation).  I think similar standards are going to
be developed by which web page designers build up their pages,
and a distribution mechanism of charges will be intrinsic. 
the author will get their desired "cut" of every transaction,
the site editor will get some kind of cut, etc.   

this really revolutionizes the idea of a magazine or editor. 
suddenly anyone on the net can become an editor or writer,
and become as financially successful as the market will support.
the "scrape off" due to enormous bureacracies (media conglomerates)
is going to vanish and be funneled into a renaissance of artistry
I suspect.

once again, I am confused why this micropayment thing is
considered so controversial and questionable to some. it
seems at the forefront of sensibility to me. clearly we
are struggling with different conceptions/preconceptions
of something that doesn't yet exist.

>As far as I'm concerned Micropayments as appealing to me as Data Mining. 

an interesting way to start off the essay, considering how much data
mining is starting to catch on and the positive, quantifiable
returns it is generating.

 I
>certainly see how my wallet would benefits from being on the receiving end of
>the money and/or information, but I can also clearly see the detrements of
>being the one whose money and information was "automagically" being
>appropriated.

can people "automagically" take money from your ATM card? nope. in the
same way, your microwallet will be secure. it will be even more secure,
because less money is involved.

> but try convincing a vendor who is already suspicious of
>'all this computer stuff' that you really sent them some money and a savvy
>hacker pilfered it all - log or no log.

there is no "convincing someone". people are using the idea of 
handing over money, of bills, etc-- all this makes no sense. it is
all handled at the transaction level. there is no subjectivity. the
vendor either received the cash or not. the cryptographic protocols
can ensure that the money is transferred. the data is not delivered
unless the payment is received. scam artists can be caught with
"better business bureau" type rating services.

>Setting a micropayment enabled web browser to automatically grant approval to
>payments of $.02/action may seem reasonable, but it depends on what the vendor
>has decided constitues an action. 
> If somone charged $.02/nanosecond for
>retreiving shareware from an FTP library, and my browser was set to accept this
>as reasonable based on the fact that it was $.02/action,

the poster clearly suggested payment PER TIME as a limit.  a pretty
obvious concept, and easy to implement, don't you think? why does it
figure as one of your major objections?

>This doesn't happen with phones (well, not as much).  The virtual nomadness of
>wandering the net leaves a lot of people - even otherwise careful people -
>vulnerable to rate traps.

it won't happen with micropayments either, because it will be *your*wallet*
that tells you when it is has an opportunity to pay. no one is dipping
into your wallet, metaphorically. the actions are always initiated by you.

>Micropayment proponents are incredibly fond of the proposition that software
>could be leased on a usage time basis from a centralized server, and people
>could also rent time on the servers' CPUs.  Sounds an awful lot like the
>mainframe days to me. 

somewhat. mainframes aren't totally the mark of the devil. don't you pay
your internet provider per hour? how many people do? isn't a Sun pretty
much equivalent/similar in processing power & capability to old mainframes?
you raise all kinds of objections that make no sense to me.

 I see plenty of ways in which this benefits the
>vendor
>(greater control over distribution, centrailzed revision/upgrade distribution,
>greater profits over one-time sales, etc.), but no ways in which this benefits
>the user.

the user is always free to go where a better vendor gives him what he
wants. because the user can now pay in tiny increments, he has enormous
increase freedom. he can move between different services far more readily.
no body is FORCING anyone to spend money. 

  Especially the power user.  I'm certainly not going to rent time
>on a compiler or image editing program every single time I want to do some
>work.

uh huh. what if over your lifetime it cost far less than you pay for
a shinkwrapped package? what if you only needed a quick compilation on
a system you don't normally use? I think you will begin to figure out
some advantages if you use your imagination to find them (instead of the
drawbacks)

> As a
>programmer, I can
>see how I could make a fat chunk of change by bilking people through metered
>software usage, but as a software consumer it seems like a rotten idea. 

you have this concept of "automated billing" that simply doesn't fit. people
know how much they are being charged. the payment is UNDER THE COMPLETE
CONTROL OF THE PAYER, NOT THE BILLER. this simple misconception seems to
underly a lot of the micropayment objections I've been seeing.

 One
>effect it would have, however, would be an exponential increase in the quality
>and quantity of software available from the Free Software Foundation and
>other similar groups as people like myself fled en-masse from commercial
>software to a
>system where we knew what we were getting into ahead of time.

or, it may be that entire new industries spring up because the software
companies are better able to be compensated for their work from skittish
consumers. people may be more free about spending micropayments than 
buying shrinkwrapped software. psychologically I think micropayments
are far more appealing in some ways.

>The other rotten part of this idea, of course, is the irritating lag times
>involved with trying to run distributed software (especially poorly
>distributed
>software, and especially on an overloaded network infrastructure).

admittedly some things have to be in place: a high speed network, and
other infrastructure ideas. it isn't totally feasible today in cyberspace,
but large parts of it are and are already being implemented (chaum's
digicash)

>Looking at micropayments from the (economically) conservative element
>viewpoint within certain industries make them seem a lot less appealing, as
>well.  Take television.  If people had to purchase every TV show they
>watched, there would be a lot less TV production going on because there
>wouldn't be as much random TV watching.

false, imho. imagine that I can buy only the shows I want to watch, and it comes
out to less than my $20 monthly cable bill. economically this is perfectly
sensible. people want to pay for what they watch. you seem to think that
micropayments means "everything costs more". a strange assumption. what if
I assume, "everything costs less" because billing costs, which other
posters have pointed out are so enormous, are vaporized?

it is true that some industries will change and meld into other forms
with this new revolutionary form of payment.  welcome to the concept of
 an economy in which anything that is stagnant tends to die.

   No matter how stupid you may
>think your customers are, if you change their pay structure they think
>about it - even if only briefly.  It would also be harder to sell TV
>advertising, because if nobody was watching a show everyone would know
>because this would be metered even better than current rating systems. 

right. shows that are not watched are going to go extinct. why should
advertisers fund them? you think that advertisers have to be fooled
to pay money to a show?

 The
>nature of the TV advertising industry would change because instead of the
>archetypal/statistical sampling of Nielsen ratings, you'd know *exactly*
>who was watching what.

that's correct. why do you suggest it would be an infeasible apocalypse?
it might be an apocalypse of old concepts, but it isn't infeasible.

>Both micropayments and data mining require that the user give the vendor a
>level of trust which most vendors are not willing to repay with similar
>trust and customer satisfaction.  Customer-users are expected to give
>vendors greater access to and control over their money and personal
>information, yet at best they can expect the same poor customer service and
>bureaucratic attitudes encountered when dealing with traditional
>transaction processing companies and at worst can expect to be swindled out
>of piles of money and/or have their
>privacy violated as a matter of course.

false, imho. again the consumer maintains complete control. in a sense
they have far greater control. if they don't like a company they
can go somewhere else after only spending a micropayment instead of
a macropayment. you may find that companies increase their level of
service and customer satisfaction. but there will probably bogus uses
that apparently you will gravitate towards, based on your seeming
preference for them.

>Working where I do, everyone around me is on the side of the vendors - who
>make up part of our client base.  On cypherpunks, of course, I'm largely
>preaching to the converted.  There can be a middle ground, however the
>middle ground that's been offered so far still leaves the consumer with the
>sort end of the stick and
>I'm not convinced they're ultimately what's best for business - especially if
>you cling to seemingly outdated ideas like good customer relations, good
>public/social relations, and long range growth relationships over short
>term
>profit pumping.

imagine shareware authors getting cash for their programs based on their
actual use. imagine artists and writers bypassing corporate monoliths
and marketing their work to the public directly, bypassing the enormous
scrape-off that these self-perpetuating bureacracies snarf.

you seem to start from the assumption, "businesses are out to shaft the
little guy". well, that can be true whether you have micropayments
or not. I doubt micropayments would make it any worse. it won't solve
the problem (I agree there is a great greed in places) but it may actually
make it far more difficult for companies to shaft people, once you think
about it. remember, the consumer has total control. how can you get
shafted when you have total control?

I've had this argument lots of times, and I tend to flip-flop between 
several positions, but I think you're missing the big big win of 
micropayments(*). Micropayments allow an individual to charge for 
information which is of value to the reader, but the magnitude of which 
is too small to handle by conventional means; for example, a single 
article or comic strip in a newspaper is too cheap to perform a complete 
SET/{VISA,MC,NOVUS) transaction for. The journalist cannot sell the work 
direct- instead she must sell the work through a middleman who takes by 
far the biggest cut. 

 Micropayments allow each author to be her own wire-service. _This_ will 
be the triggering point for the new media. These services can be combined 
into edited newspapers without the editors needing to set up complex 
traditional arrangements (I'd pay for John Young's Daily News :)

Freedom of the Press belongs to those who own the vending machines

Simon


(*) For the purpose of this message, micropayments are defined to be low 
value transactions below the minimum values acceptable for conventional 
payment networks



---
Cause maybe  (maybe)		      | In my mind I'm going to Carolina
you're gonna be the one that saves me | - back in Chapel Hill May 16th.
And after all			      | Email address remains unchanged
You're my firewall -    	      | ........First in Usenet.........

-----BEGIN PGP SIGNED MESSAGE-----

Simon Spero wrote something like:
>
>  Micropayments allow each author to be her own wire-service. _This_ will 
> be the triggering point for the new media. These services can be combined 
> into edited newspapers without the editors needing to set up complex 
> traditional arrangements (I'd pay for John Young's Daily News :)
> 
> Freedom of the Press belongs to those who own the vending machines


There are three things necessary for the New Media Paradigm to
take full effect:

1.  Many-to-many connectivity.  Check.  (infinite bandwidth blah
   blah..)
2.  Micropayments.  Coming soon to an electronic wallet near you.
   (Ecash(tm), bearer bonds, cheap tokens, coupons, blah blah..)
3.  New ratings systems.  Um...  Well, it would be easy to do 
   but few people seem to have really caught on to it yet.  
   I remain hopeful that it will come to pass as millions more
   come on-line and cetera.  I suppose having a certificate
   standard and a public key authentication infrastructure might
   help, although I secretly suspect that the good ole' Web O
   Trust would be sufficient for this purpose.  (After all, you
   only really take ratings from people you know, right?  Or
   people who have a "reviews" column in your local newspaper.)


Of course, despite all of our fond techno-utopian daydreams,
there is no telling whether this New Media Paradigm with its
absolute freedom-of-the-press and its free (or at least cheap)
presses is going to be good or bad for the current pop-culture
millionaires and the ugly tripe that they peddle.


Bryce

#include <stddisclaimer.h> /* Not speaking for anyone else at this time. */
- ----- BEGIN GOODTIMES VIRUS INNOCULATION -----
Once you have read and understood this .sig, you are immune 
to the Good Times virus.  Please help spread this innoculation!
- ----- END GOODTIMES VIRUS INNOCULATION -----




-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.1b2

iQB1AwUBMb7UQkjbHy8sKZitAQGg/wL/SDjAXkMH+pwwMIUONtXaWxDAMjNose0R
BCfQxFhTMqUUl1JwbYaX61X/L3ckm9/83+3uuFNeT/x/dsKcmIhVmalTBobdEWPV
XbvI/fsokUY0lahjmbgcsR0EmriS+F5L
=+T9Y
-----END PGP SIGNATURE-----

Stephan Vladimir Bugaj writes:

 > Setting a micropayment enabled web browser to automatically grant approval to
 > payments of $.02/action may seem reasonable, but it depends on what the vendor
 > has decided constitues an action.  If somone charged $.02/nanosecond for
 > retreiving shareware from an FTP library, and my browser was set to accept this
 > as reasonable based on the fact that it was $.02/action,

You could also set a per-site limit, or a per-minute limit.

 > It took the industry long enough to get PCs and workstations to the
 > speeds they're at today so people could do their own work on their
 > own machines to go back to waiting in a queue for time on a
 > centralized system so you can have the honor of paying someone a
 > lot of money to run your job.  As a programmer, I can see how I
 > could make a fat chunk of change by bilking people through metered
 > software usage, but as a software consumer it seems like a rotten
 > idea.

Oh?  Would you rather pay $5,000 for some vertical piece of software,
or license its use on a $1/hour basis?  Even if you used it every hour
of every workday, that's only $2,000.

 > Looking at micropayments from the (economically) conservative element
 > viewpoint within certain industries make them seem a lot less appealing, as
 > well.  Take television.  If people had to purchase every TV show they
 > watched, there would be a lot less TV production going on because there
 > wouldn't be as much random TV watching.

Um, you *do* purchase every TV show.  On the fly.  30 seconds at a
time.  Of course, some cheap people try to welsh [ see my hostname
before taking offense ] on their payments by Going To The Bathroom
during their payment periods!  Disgraceful, just disgraceful.

 > Both micropayments and data mining require that the user give the vendor a
 > level of trust which most vendors are not willing to repay with similar
 > trust and customer satisfaction.  Customer-users are expected to give
 > vendors greater access to and control over their money and personal
 > information, yet at best they can expect the same poor customer service and
 > bureaucratic attitudes encountered when dealing with traditional
 > transaction processing companies and at worst can expect to be swindled out
 > of piles of money and/or have their
 > privacy violated as a matter of course.

Hmmm...  Sounds like a job for ...  Super-Shameer!  Profit-making
super hacker privacy protector!  His mail flies through remailers with
the greatest of ease, he's invincible to flames, and and he is cute,
too!

-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | PGP ok
11 Grant St.      | +1 315 268 1925 voice | It's no mistake to err on
Potsdam, NY 13676 | +1 315 268 9201 FAX   | the side of freedom.