Slashdot Mirror
Ron Rivest Suggests Probability-Based Micropayments
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."
Ok, randomization has its uses, but what advantage does it have over just waiting till the micropayments sum up to $10 and sending them then?
Sounds, from reading that short article, like the merchants must trust Peppercoin? Why should they?
Belief is the currency of delusion.
Same old, same old?
"To any truly impartial person, it would be obvious that I am right."
For the user, sign up for a PepperCoin account, providing your credit card number, and when you want to make a purchase:
The token is a digitally signed token with the merchants "name," the consumer's "name," the amount of the transaction, and a value of either $0 or $10 (to the merchant.) Your PepperCoin account is charged $0.50.
The merchant, upon receiving a token, sends you the product, and if the token is worth $10, keeps it for later.
At the end of the [day / week / month / quarter] send all the $10 tokens to PepperCoin. PepperCoin sends back the money for the total value of the tokens. What you'll find is that (money received) / (total number of tokens collected) is $0.50. The merchant will be charged a fee for the service, so you might see something like $0.45 per purchase (10% fee.)
Back to the consumer ... over time you'll accumulate $10 or more in purchases at which point your credit card will be charged. If, let's say, 6 months elapse, and you still haven't accumulated $10, you'll be charged your current balance.
See ... PepperCoin makes about 10% of all the purchases minus the cost of credit card transactions to the consumers (about 5%), the merchant gets $0.45 instead of $0.20 on a $0.50 purchase, and the consumer is charged dollar-for-dollar what they spent.
--- Jason Olshefsky
Karma: Poser (mostly affected by adding this line long after everyone else did)
... it's the credit card company charging so much per transaction. Why work around that problem?
The "market" for credit cards is skewed because the transaction charge is applied to the merchant rather than the purchaser. If the charge did come direct from the purchaser, the purchaser would choose a credit card that offered the lowest charge. As it is, the merchant has no choice (other than saying "I don't accept Amex), so competitive pressures don't apply.
Peppercoin-type operations will further mask the skewed market - we will all end up worse off; except of course for the Visas and MasterCards of this world.
Rob.
My guess is this system was likely not designed for use by run-of-the-mill merchants with transaction volume below the millions (and conceivably billions). Like many have pointed out, your typical store merchant would laugh at the prospect of roulette-based revenue.
This system was designed to solve the problem of handling billing and payment collection for A LOT of transactions per unit time. Think NASDAQ. Think VisaNet. Think McDonald's-years. Think pay per wireless packet, a concept routinely floated by Rivest's MIT colleagues including Dr. David Clark.
Coupled with a computationally efficient token verification scheme, I could see how this system could turn standard billing practice/procedures on its head, provided the big corporations have enough smart people in their stables to say, "Rivest is right." For instance, if my statistics memory serves, this system should effectively enable stepless billing (without increments or round-off issues) - in other words, finest-grain discrete-time pro-rating for services provided, tunable per application to some arbitrary epsilon.
I think music downloads are a red herring. It's entirely possible that PepperCoin will never see the light of day as a consumer payment service. But I'm very curious to see what the world's largest accounts receivable departments have to say about it.