Ron Rivest Suggests Probability-Based Micropayments 336
Karl J. Smith writes "Rivest has solved the micropayments problem with encryption and statistics. You throw away some transactions so that you don't have to pay bank fees, and process the rest. Hiawatha Bray has written an article and Rivest's new company is PepperCoin."
Full text of article (Score:2, Informative)
Solving the problem of micropayments
By Hiawatha Bray, Globe Staff, 2/17/2003
IT professor Ron Rivest has come up with a new way to throw away money on the Internet. With luck, it'll make him a fortune. Rivest is one of the three people who devised the encryption system that allows us to transmit our credit-card information safely over the Internet. The company that grew out of this work, Bedford-based RSA Security Inc., is one of the leaders in the field. He's a fellow of the American Academy of Arts and Sciences and the Association of Computing Machinery. Put it this way: Rivest knows what he's doing. So what's all this about throwing away money?
Actually, it's a fascinating proposal for solving one of the toughest -- and smallest -- problems of Internet commerce. It's easy to buy a $20 CD online, or a $100 hard drive or a $20,000 car. But how do you buy something online when it only costs a buck or two?
This is what's called a micropayment, and it turns out to be remarkably difficult to do. Entrepreneurs have been banging their heads against this problem for the past half-decade or more, and with good reason. There are lots of desirable digital products that might sell like popcorn if there were a practical way to pay for them. Music, for instance. Some subscription services will let you download tunes at 50 cents apiece, but you have to pay a subscription fee as well. We're still waiting for a service that lets anybody drop by at any time, and purchase a single song.
This is because it costs so much to process a single financial transaction. Most Internet shopping happens with a credit card. The merchant selling the goods must pay a transaction fee to the credit card issuer. This usually amounts to a few percent of the sale price, plus a flat fee of 25 cents or so.
But this flat fee is the same no matter the size of the purchase. When the merchant is selling Tom Clancy novels at $30 apiece, the fee doesn't matter. If it's an MP3 of the latest single from Sheryl Crow, that fee will eat up all the seller's profits, maybe even put him in the red.
''You can't do small payments with credit cards,'' said Rivest. ''From the merchant's point of view, you probably can't do under $5 and make a profit.''
What's needed is a method that slashes the cost of the transaction. Enter Rivest, his colleague and fellow computer scientist Silvio Micali, and their new company, Peppercoin Inc., which plans to solve the problem with doses of encryption and statistics.
The service will be free to consumers, who sign up with Peppercoin and provide a credit card number. Now the user can go to any Peppercoin retailer and purchase a single, very cheap item -- an MP3 song priced at 50 cents, for instance. By clicking on a link, the music gets downloaded to the customer's computer. The merchant gets a Peppercoin -- a sort of electronic token that's got the customer's digital signature embedded in it.
What's the token worth to the merchant? It depends. Peppercoin uses an algorithm that assigns a value to the token. Actually it assigns one of two values. Either the token is worth some preset amount -- say, $10 -- or it's worth nothing at all. When the token is worthless, the merchant throws it away. When it's not, the merchant collects $10 from Peppercoin, even if the customer only spent 50 cents.
It seems utterly nutty until you apply this method to millions of 50-cent transactions every month. Maybe 5 percent of these transactions will be sent to Peppercoin, which processes them through the credit card system. The rest are thrown away. This keeps transaction costs way low. And the transactions that are processed have a value of $10 apiece, which brings in cash to make up for the 95 percent that were thrown away. Spread over millions of purchases, it all averages out.
But even if Rivest's math is correct, the success of Peppercoin is far from assured. The dot-com graveyard has a special section for companies like Digicash and Cybercent that failed to solve the micropayment puzzle.
''A payment system is a real chicken-and-egg problem,'' said Rivest. Consumers won't embrace the system unless lots of merchants accept it; merchants won't sign onto the system unless the customers are there. Peppercoin hopes to break the cycle by signing up some major media companies in time for its debut later this year.
Letting consumers buy hit music recordings for a buck or less, without charging $10 a month in subscription fees, could be just the thing to ignite the micropayment market. And if more consumers sign up for Peppercoin, more vendors will start offering products -- magazine articles, digital games, even those annoying cellphone ringtones. Many of these goodies will be items that are presently given away, because there's no efficient way to charge for them.
With Peppercoin, companies will be able to make us pay. And at the microprices made possible by his software, Rivest figures millions of us will be happy to let him throw our money away.
Hiawatha Bray can be reached at bray@globe.com.
This story ran on page C4 of the Boston Globe on 2/17/2003.
© Copyright 2003 Globe Newspaper Company
Re:Why randomize? (Score:0, Informative)
Though I equate this to be better than the losses many e-companies are seeing from theft (or copyright infringement). And unfortunately, I think it is more appealing to your average schmuck.
Still, I like the random idea. I think another way to make it more acceptable to the masses is to assure them they won't get hit for $10 until they've purchased at least $5 worth of goods. I think as with all things now, retailers (and maybe banks) need to dangle some free carrots to get people to buy into the system.
Whatever algos are chosen, they need to allow people to do some fairly fine-tuned budgeting, and they need to have a way to weigh the random-ness to prevent that millionth customer from getting hit 10 times in a row.
I think with the right FAQ, this idea could be successful.
Re:Why randomize? (Score:5, Informative)
I suspect that on the customer's end they will solve the micropayment problem by forcing the customer to deposit a minimum amount (say $10) into his Peppercoin account, rather than charging every nickel and dime he spends separately. The customers will not mind if they expect to be able to spend these Peppercoins on many goods and services. Thst is where the chicken&egg problem comes in: if there are only a few sites accepting these coins initially, no one will want to depost the minimum $10 to activate his account.
Re:Not to be the cynic? (Score:3, Informative)
There doesn't seem to be one... [paypalsucks.com]
Small sample statistics problem? (Score:4, Informative)
What about the retailer that doesn't do a heavy volume of business through PepperCoin?
For example, if it's a 50/50 probability that a given coin is worth High or Low and you flip that coin 100,000 times, then within a minimal error, the coin will be 50,000 High/50,000 Low. But what about a retailer that only does 1000 or 500 or *less* per month.
Then, add on the fact that the PepperCoins being discussed aren't necessarily 50/50 but sound more like 5/95 or 1/99. If you closely examine any 500 of those 100,000 tosses earlier, you can probably find quite a few runs of 500 lows or more in a row. Suddenly, there are whole months that a retailer is going without payment to wait for that one time when they get compensated waaaay down the line. It seems a feast-or-famine proposal for the smaller retailer.
Sounds like pepperoni to me. (Score:3, Informative)
Only a certain number of customers will reach this break-even in a given time-period.
The value of a "winning" Peppercoin to a merchant would be this break-even amount, minus the credit card company fees and Peppercoin fees.
The odds of a merchant getting a valid Peppercoin would be based upon the number of break-even transactions made in say, a month.
If 10,000 total transactions were made in the first month, and only 100 people spent more than the break-even amount, say $12.50, the odds of a given coin being worth $10 would be 1/100.
It's a novel system, as previous efforts to deliver microcash required customers to buy tokens in advance. This system places the risk upon the merchants, who are being asked to gamble that people will use Peppercoins on a regular basis.
As a system like this matures, it could actually work, maybe.
Re:Why randomize? (Score:2, Informative)
Re:Small sample statistics problem? (Score:2, Informative)
Then they should probably re-think their business strategy.. we are talking micropayments here. Less than 500 micropayments a month isn't exactly big business..
you can probably find quite a few runs of 500 or more in a row.
Err.. no. Not really. 2 raised to the power of 500. That's pretty darn unlikely. Actually 1 in 3.2734*10^150 unlikely.
The phenomenon isn't as bad as you think (Score:2, Informative)
Your expected income is in fact $10000 while your standard deviation is 10(20000*.05*.95)^(1/2)=$308 or so. So while the variation is painful, it actually turns out you'll be in the $9000-$11000 range 99% of the time.
Similarly, if you scale down by a factor of 10, so you have 2,000 coins. Your expected income is $1000 while the S.D. is 10(2000*.05*.95)^(1/2)=about $100 or so. The 95% range here would be from $800-$1200, which is more painful but still managable.
The odds of a run of 500 lows in a row is about 7.27*10^-12, safely ignorable
There is already a working micropayments system (Score:3, Informative)
A related approach (for donations only) (Score:3, Informative)
Monte Carlo pledge fulfillment [buskpay.com] for the Buskpay microdonation system [buskpay.com].