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
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. 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
-----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-----
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.
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-----
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.
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
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 ]
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.
participants (14)
-
Brian Behlendorf -
Bryce -
bryce＠digicash.com -
Darren New -
Einar Stefferud -
Einar Stefferud -
Hal Varian -
Jeff Barber -
nelson＠crynwr.com -
Paul Rarey -
Simon Spero -
Stephan Vladimir Bugaj -
szabo＠netcom.com -
Vladimir Z. Nuri