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."
Yes, that is the way to make micropayments take off: patent them.
Most people's number skills are so poor that they probably won't understanding or trust it.
Mmm, tempting!
And who said you can't still do over people for VC?
"To any truly impartial person, it would be obvious that I am right."
... how much are the end users getting charged for this?
Are they getting charged 50 cents for each transaction, or are they often getting charged nothing, but 1 in 20 transactions they get charged $10?
This confuses me. I don't get how this is any better than the subscription thing. Sounds like you just have to subscribe to one central site to cover a lot of other sites - much like getting an MS Passport, only with payment for this one. Or how Visa centralises credit card transactions. Buffering up micropayments until they pay enough - doesn't Paypal do that already?
Hmm!
E000-VB14-G8RY
That's cool, it'll be a new way for a company to justify high losses: 'no sir, our product isn't crap, we are selling many many; we just are unlucky with Peppercoin, only getting useless tokens...'
Tsuyoikoto ha taisetsu da ne, dakedo namida mo hitsuyousa (Strength is an important thing, but tears too are necessary)
So, if I read that article correctly, I can hypothetically buy 20 songs for $10, and 19 are free, but one is $10.
So if I buy one the first month, and a $10 charge shows up on my credit card, I will be pissed, and never use the system again.
If I buy one the first month, and there is no charge, then I see how I can beat the system - just keep getting new accounts.
Sorry, Ron, I think you need to re-think this one.
I've got nothing against micropayments, but this guy is just sometimes too smart for his own pocketbook. I mean, doesn't he already have a solid gold house?
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?
Once the means to collect it was in place.. see what happened?
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
Sounds, from reading that short article, like the merchants must trust Peppercoin? Why should they?
Belief is the currency of delusion.
Is this a lottery on whether you get charged or not? I'm sure that if I used it it I'd be to only one that has to pay $10 every time. The article doesn't make this at all clear.
I understand the idea of using statistics to reduce the number of transactions with the same results, but I don't understand how Peppercoin makes up the difference. A credit card still needs to be billed in the end, right?
If I buy the $.50 music track online, I as a consumer still need to be charged $.50. The only method I can see to make this worthwhile is grouping the charges. ie. Peppercoin charges each consumer once a month/when a set amount is reached.
But how does this differ from a micropayment system without the statistical gimics? I don't quite grasp the advantage of using this token system. Merchants who are using Peppercoins as currency are already operating without credit card per transaction fees, so why does it matter how many tokens are redeemed through Peppercoin?
Obviously something is going on here, but I don't get it. Can someone clarify a bit?
One thing for sure, they PROBABLY wont get my money.
In cause we manage to /. the server
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
Everything in the world is controlled by a small, evil group to which, unfortunately, no one you know belongs.
Cmdrtaco and Micheal "censorware" simms have come with with a new way to crush trolls. Every time you post a -1 troll, you pay 1Ââ. (microeuro). On average there are only around 100 troll posts a day, so it will take approximatley 10 days to make 0.1 eurocents from trolls. Of course, the real money is from selling mod points, which will cost $10 each, so pay up or get trolled!
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
I gather that the event of a transaction to a vendor happens with a certain probability, and on vendor's side, law of large number sets in.
But what happens on consumer's side?
If I read one article per month, worth, say, 20 cents, do I pay 20 cents to Peppercoin with p=1 or 10 dollars with p=0.02? Consumer's transactions may be too low to obey law of large numbers.
But what is the difference of this and PayPal???? Ok there is some more math.
But I thought part of the problem was using PayPal is that PayPal is an external service that is not as recognized as Visa, Mastercard, or American Express (plus some others).
And this service does not seem to solve that problem for me. I thought when I started reading the article that it was going to somehow have some magic receipe for using my ALREADY accepted credit card....
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
So what makes Ron Rivest thinks he might be able to solve this where other failed?
A key success factor of this business is trust. But unfortunaly for non-geeks, trust is hardly based on transaction security, but merely on the wealth of the company.
Microsoft tokens won't have the same trust factor as Linux tokens (for example), and customers won't buy tokens that could well be worth less than nothing, if the market decides that way.
Would you really invest a penny (because that's what is's all about : invest money) in peppercoin?
Violence is the last refuge of the incompetent - Salvor Hardin
I noticed the Peppercoin site did have any overt mention of a robust privacy policy... something that micropayments must include for people to actually trust it.
One can argue that RSA set back security for normal people by many years. Phil Zimmermann changed this with the open source PGP. Peppercoin sounds like the RSA of micropayments.
So I'm going to wait for Pretty Good Payments.
Micropayments are ok
But what we REALLY need are micro bills
Is this meant to be "product gambling"? Because the money still has to be collected from every consumer, unless you want to charge a whole lot of them $0 and a few $10 each. Credit card fees still have to be paid, in this case by Peppercoin, Inc.
Don't even try to tell me that Peppercoin sets up accounts for you to keep transactions rare and juicy. PayPal was faster on the draw.
MIT professor, huh? Well, can't wait to see what's next. Maybe a new, ultrasecure symmetric encryption?
The difference between ignorance and apathy? I sure don't know, and I don't care either.
What is the point of a retailer collecting these PepperCoins, then sending them in, with 5% of them being worth $10.00, and 95% of them being worthless? If you're going to have a clearing-house, why the hell wouldn't you just have the retailers collect the PepperCoins and send them in for a guaranteed 50c each, but just not do it until you've collected at least 20 of them?? It'd have the same "avoiding credit card fees" effect, but without the stupid randomness which, even if it does balance out perfectly over lots of transactions, will completely turn off the vast majority of retailers.
I don't understand this. Does it mean that sometimes my card will be charged, and sometimes not? If I buy just one MP3 (or whatever) online, could I be the unlucky Joe who pays for 9 other people too?
When I am king, you will be first against the wall.
This is a hard sell for all involved i think.
For the Merchant
"....That's right Mr. Merchant we will allow these anonymous customers to log on to your system you give them your products, and they can pay with our tokens that are worthless 95% of the time, but you'll be ok in the long run. Um no we are not like those other dot.com companies that are not around for the long run..."
As well as that what is the advantage to the customer?
I can see how the law of averages works (or works more quickly) for the Merchant, but picture the situation that I buy one item per month for 6 or 7 months @ 50 cents a go, but due to randomness I am included in the 95% of those tokens that are thrown away. Then on the 8th month I get hit by a 10 dollar charge for something that should cost 50 cents, and even assuming I remember I have had 7 freebies, I am still out of pocket. This means I have to keeping buying, and hope that I can get 10 dollars worth of stuff, and then get out before I get hit again for another $10. This then leads to abuse/gambling, how much stuff can I get without getting charged and then get out or quit?
Or am I missing something?
--My sig is bigger than your sig--
this looks like hidden advertising to me but i won't argue that point....
and it's based on 'patent pending technology' that is somehow acceptable by slashdotters (see here for more info)
this sounds like a lot of marketing hype. why not just have a company that processes micropayments in mass -- if i buy 10 songs for $1.00 each from 10 record labels during 3 months i should be charged $10 as soon as it is profitable to charge me, possibly at the end of the three months, possibly after my tab is at $5.00. i think this is basically what happens with peppercoin but in a more complex, mathematically obtuse way.
finally, what's up with all the hot women on the peppercoin page? it's like i'm supposed to be able to buy them with peppercoins.
fear is the mind killer
I guess that he means that the token is random on both sides (also on the consumer side), which is a good idea when the token value is never more than a few dollars, but I doubt this would easily be accepted due to obvious reasons.
http://www.gnu.org/philosophy/words-to-avoid.html
the procedure is *obvious*...
1) user buys $0.50 token from Rivest
2) user transfers $0.50 token to store
3) that token is *re-valued* at the store to either $0.00 or $10 (using the article's example)
IOW, the end user only put out $0.50 -- the store gets either $0 or $10 -- each token would have a 5% chance of being worth $10.
Nice solution, Ron.
Can I throw away some 5%-10% less invoices?
And by the way, Your Telco has a micropayment solution since ages. Your Mobile Operator also.
It's called phone bill.
Don't know were I read it several years ago:
"The (Business) Model of a (3G) Operator is the Business Model of a bank"
chess
Ok, a business plan joke:
0. Become Rivest.
1. Change the winning probability from x to x-0.0001%
2. Transfer the 0.0001% of revenue to a private account
3. Profit!!!
The 'angle' here is that, by reducing the number of transactions required for the merchant to collect payment, they're making it more profitable for merchants. At the moment, merchants can't flog things for 50c each using Visa, because the Visa transaction charges mean they actually make a loss on each purchase.
Thing I don't understand - Peppercoin claim if you only buy one MP3, you'll only be charged 50c.
So how can Peppercoin charge 50c to my Visa card without putting themselves out of pocket due to transaction charges? Or are they hoping I'll be an insignificant minority and that everyone's gonna use this thing so much that the transaction payments will become insignificant?
OK, Rivest's a smart guy and micropayment is a hard problem, but this just sounds like so much BS right now...
---- Open Source: It's mad, but you don't have to work here to help.
actually, i noticed there are several men there too.
but this marketing tactic, though hardly uncommon, unsettles me in this instance. this is supposed to be a financial institution and they fill 1/3 of the screen with hip, attractive models (some are actually disgustingly skinny).
whatever, i'm sticking with my first assumption that this slashdot submission is entirely a marketing ploy and i hope everyone involved with this company gets diarrhea and their car tiers go flat on the way to pickup medicine.
fear is the mind killer
Okay.. from the merchant's side.. he does not wanna mess with trying to account for a 5 cent sale.. so lets calculate the a 0.005 probability ( thats 5 cents out of 10 dollars ) and assign that probability to a ten dollar token, that the token is any good. So, in effect, the merchant is gambling he is going to get paid - in this case, for the sum of 5 cents, he accepts a 0.005 probability he gets $10. Basically, its just like gambling, where PepperCoin is the "house". But over millions of transactions, statistics would approximate the same return to the merchant as if he tallied all the micropayments.. but the merchant does not have to worry with millions of tiny payments, he works with thousands of larger consistent payments. And is willing to accept the accounting simplicity as tradeoff against any probability error, as well as the overhead of the "house cut". This technique allows the processing of billions of payments without keeping detailed records on each... the only thing going through is the statistical averages of who gets paid what.
Well anyway, thats my *understanding* of how this thing works...
One neat thing is that it appears any identifying information to the purchaser would be lost in the "noise". comments invited.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
Sounds like an awfully potent marketing - user tracking system... All in the hands of one company... Big privacy issues it seems to me!!!
-- Windows has detected that your mouse has moved. The system needs to be restarted for the changes to take effect. [OK]
I have only read it quickly, but there seems to be no mention of the way PepperCoin will charge the customers. Since the PepperCoins' value is transferred from PepperCoin to the merchant and this transaction is "optimized", the other transaction (PepperCoin <=> customer) is important. It seems to me that this would only(?) work with a pre-paid amount (otherwise the customer would have to purchase frequently enough to be charged for several transactions at once), so the claim from the article: 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. is questionable.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
The first thing that sprang to mind when I read the title was the Infinite Improbability Drive from HHGttG. :)
is that the merchants and PepperCoin don't need to process each digital coin. Statistically the issuer only need to process(verify and pay-up) 5% of them. If you could see that the cost of issuing a digital coin is relatively low, then the cost of this micropayment method is only about 5% as before.
:)
It's definitely a breakthru in micropayment as it lowers the cost of processing used digital-coins. In the past other micopayment issuers attempted to fix this problem by allowing reuse of paid-coin like we do with papernote. It doesn't work as you can see, because merchants always wants to cash in asap, and they don't care if that'd increase the burden of micropayment issuers, this is just not their bussiness.
One of the problem I can see is the fairness. Would that be one extremely bad luck dude keep getting null coin and compain about it? I know it's unlikely in statistical sense, but I DO keep drawing lousy trading cards so those people like me would worry.
Btw, those who compare it to Paypal can move along. First of all Paypal charges flat for each transaction and ALL payment methods requires you to prove your credit and your ability to pay back. Credit card is just one of the method for this purpose.
He gets to keep and use the money until it hits the payout?
Nice one. Stretch it by splitting SKUs and more time to use them bucks.
The chicken and egg problem still seems to be around: In order for a company to be able to use micropay, it needs to have transactions occur in sufficient quantity that the law of large numbers applies and the payments average out to the correct amount.
If you're a startup looking selling something like MP3's online, however, then you will most likely start with a small customer base. Should you just hope for the best on those first few hundred transactions?
credit cards pose a secutiry risk (both for in-country and foreigners), independent of how good encryption is, there is always the human factor on the other side. The moment you give the card number, independent of the buy being $ 0.50 or $ 500, you are at risk. The micro-ness of the values only bring more risk of security look-overs.
If that's not enough, international credit cards are not easily available to everyone, especially young, income-less students, who are a considerable part of the "people who use the net" and are likely to be the main targets of such "content producers".
International bill sending poses more issues than any merchant is willing to face.
The only way for this to work is if a multi-national company sets up a station on every target country (US, Canada, all over Europe, probably South America and some places in Asia too, for most businesses) for selling net credit. Of course this company will be a monopoly, which isn't good; Moreover, politicians would come up with lovely absurd taxes on such services (allowing citizens to mess freely with the external debt is a bad idea, anyway), and the micro-payments would no longer be micro.
It may work for small segments and businesses, which is enough to get this yet-another-dot-com in the blue, but micro-payments aren't taking over the "content industry".
and the cc transaction processing companies could lower their per txn fee, in the hopes that they make more money b/c of micropayments.
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.
Mordor...a magical, mythical land where women are more rare than dragons--but where every man would rather find a dragon
It clearly states on the site that the consumer gets charged and the merchant gets paid. Honestly, you people really should learn to fvcking well read!
No, peppercoin.
That's what I said, peppercorn.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
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.
I urge you to STFU. I bet you weigh 400 pounds and smell like fried pork rinds.
I think if you randomize you will get a chance to fudge some data; I mean, if in the end your average price of item turns out to be like 49.68 cents averaged over long term, you will have a very unlikely chance of noticing this discrepency. especially most (ALL?) financial software rounds to the cent.
At the same time, the above is assuming that EVERYTHING is 50 cents. Now, imaging there are things costing different amounts of money, and calculating if papercoin is ripping you off that 0.3% becomes difficult if not impossible.
Now, of course, I can't quite figure out how does papercoin charges the consumer. That's really weird because THEY can't be hit with the 25c charge everytime either or they will go under; so they will either have to
1) act like a bank / paypal and have you keep a balance.
2) wait until your "sum" is large enough and charge it all at once.
both have serious problem.
Of course - this entire thing is really a credit card system problem, that can really only be solved by the credit card companies - but they seem to have no incentive to do so, so... we might be stuck here for a while.
My life in the land of the rising sun.
Micropayments are things like USD 0.0002 per Slashdot page. USD 0.50 is hefty. Let's call this minipayments or something.
The problem with real micropayments is user control. Users like to know how much they are spending, but they don't want to click a confirmation box on every downloaded file.
Technically knowledgeable people are usually terrible at marketing. The Peppercoin web site is one of those "Click here to get the plug-in" web sites. (Last time there was a big security vulnerability in Flash, I uninstalled it from Mozilla.)
A play on words like "Peppercoin" is rarely successful marketing. People want to be able to trust a company. They don't want a small joke.
Well I'm still trying to figure out how I "paid" VeriSign by sliding a $20 bill inside my computer. I heard some snickering from the customer service rep that told me to do it but I figured it was in reference to a joke I didn't hear.
Small potatoes make the steak look bigger.
Peppercoin accounts are backed by a bank account, usually via a credit or charge card.
That is the death knell. Any system that interfaces to credit cards or bank accounts but which doesnt have some utterly compelling extra feature is going to fail, especially when there are services like PayPal already dominating the market.
Any point of friction, like having to sign up for a bank account to spend money will instantly limit the uptake. Merchants will become disenchanted with the lack of customers, and stop converting their content to peppercorn files.
If opening an account is not a three field form, then forget it. This is the true problem of micropayments; how to give away the user accounts to create a huge spending population.
ATH0 Bitcoin: 1DnwFLXczVZV8kLJbMYoheUrpqHesjxrSi
These guys are doomed simply because it doesn't really cost Visa/MasterCard/etc that much to process a transaction. They charge it because they can get away with it.
As soon as any scheme like this becomes even remotely successful, the credit card companies will change their pricing models and steal the market.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
The correct solution is to batch micropayments together and fire them all at once, like pre-sorted mail. To reduce transaction count, the effective change in monies among large money holders is the only thing that needs to be computed (i.e., your individual monies are held by some big dogs), companies just need to keep micropayment logs to prove that they charged things and have automated random audits. With the invention of the Internet and other interconnected WANs, there is no execuse for transaction costs above .01, as packets are FAIAP free.
/. == dot-com-promo-as-news-adserver; biggest racket in the world: banking & CCs.
Banks are just being ghey when they charge fees to use/get you own money. That's how they make money, that and loaning your money out. Someone should come along and offer something w/o so many fees, oh yeah... paypal as a micropayment system. who needs this? just use PAYPAL!
For a real solution, a gov't-backed universal electronic money interchange standard w/ varying levels security and tracing needs to be adopted. the real problem with that is authenication (who's certificate authority) and trust (network, terminal, physical, etc).
if this guy found a way to stop spam, that *might* be news.
No, the customer get's charged.
But the term lottery is very good in this context. Let's look at the scheme from that point:
If a state organizes a lottery (at least here in Germany) it is obliged to pay out at least 50% of the money that came in from selling the lottery tickets. This payment occurs in the same random fashion like the pepper coins.
In reverse, a customer of a lottery can roughly except to win back about 50% percent of what he shells out (it depends on the time frame and how all the win money is distributed among different winning ranks).
The same holds for the merchants participating in that peppercoin scheme. Statistics is on their side. The more transactions, the smaller the error margins.
I would call the scheme a reverse lottery.
The critical point is of course the tuning of the propabilities in the win/loss one time pads that Rivest's company is likely to distribute to the client software. He can make money by having to low win probabilities.
As a participating merchant I would perhaps insist on a contractual margin - if I have N zillion transactions there should be guarantieed error margin. If my pepper coins are below that margin, I should get compensated by Rivests company, if I'm above I should pay back.
The general idea, to use statistics to neglect expensive detail, seems very good to me.
Regards,
Marc
(OK, so it's a contentious subject line :)
:)
But Telecom companies already charge tiny amounts for services, they have the structure in place to do so... I get charged a minimum of UKP0.05 for every phone call I make.
So all we need is for the seller to charge the telco handling your Internet Connection (dial-up, cable modem, ADSL whatever).
So for example, I log online with BT and surf to mp3.com. I ask for a $0.25 MP3 file and mp3.com checks my IP, spots I'm at BT and asks for the cash FROM THEM, NOT ME. (Insert foolproof authentication here, of course).
When I get my next monthly bill, I have an additional $0.25 charge on it, hopefully with some information regarding what it's for. I pay my bill as usual (relatively large numbers so it's easy).
Assuming BT and mp3.com trust each other, they can agree to settle the bill for all BT's customers when it hits $10, $100 or $10,000 if they like. Or BT can pre-purchase 'tokens' from mp3.com and use them up as and when their customers buy stuff.
Sounds exactly like PayPal, doesn't it? Except I trust my telco not to rip me off, I don't (usually) need to pre-charge my account, and the economies of scale mean it's easier to kick off - there are a huge number of customers for the average ISP, so they can all start trying this out without stuffing $10 in a Papercoin or PayPal account, which might be usable in all of 3 online shops.
Now let the flaming begin
Liked this comment? Why not buy me something nice
Let's say you're a firm hoping to make $10,000 in sales in the next month, corresponding to 20,000 Peppercoins. Each peppercoin corresponds to a random variable which is $10 with probability 0.05
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
I'm unsure how the tax system works on the U.S., but I hear that every transaction is taxed, even if they form a chain. So, one transaction with this system comprises these steps:
- I buy peppercoins from his company.
- I exchange those peppercoins for a music track.
- The third party sells their peppercoins to his company.
Assuming Internet transactions get taxed, won't we get taxed twice or thrice because of this?
Really.
Quote: "Just my $0.02US"
Is that in peppercoins, or real payment?
You make an account at peppercoin and register your credit card.
You find a place where you can by with peppercoin. You write your account name and password.
If you by for 0.05$ peppercoin will only charge you 0.05$. NO credit card fee.
The idea is they hope that people in time will have many micropayments each, so when they once a month (or how often they will charge you credit card) you have bought enough to justify the credit card fee.
So if you buy for 0.05$ your entire life with peppercoin, then yes peppercoin will have paid for your transaction.
BUT remember there is also a moneytransfer to the place where you have bought for 0.05$.
This is where the idea of randomisation comes to play. The shop really don't wan't to have transered money to their account for every sale, so instead they get money 'sometimes'.
This have the advantage of security - the shop don't have to trust that peppercoin keeps track of every sale.
Instead of using their "tokens" we can use MMRP money. Once you get 5000 "pyreals" or "gold peices" you can sell them on ebay! Well, maybe there's no difference.
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.
Hi All
After reading Bray's article, I have a few comments to make:
First, payment to end users must be deterministic. As many other have commented, end users will not adopt a system where they are exposed to statistical payment schemes.
Payment to vendors is stochastics. Each peppercoin has the same expected value as the good being sold. Vendors only redeem "winning" tokens. I would expect [but do not know] that the standard deviation of the the peppercoin's value is configurable. There should be a relationship between the processing fee and the standard deviation of valuation.
Validation of Peppercoins is fairly simple. The same sampling mechanism that are used with physical inventory can be applied. However, since validation cost is much less, I'd have much more faith that I'm not receiving "bogus" peppercoins.
One point that no one has mentioned: Peppercoin.com will need to maintain a "slush fund" to protect against a run of bad luck. This has the potential to have a significant effect on operating costs.
All in all, this sounds like a fairly elegent solution to a real user problem. I like its.
what's up with all the hot women on the peppercoin page? it's like i'm supposed to be able to buy them with peppercoins.
you mean like this one?
or a little buddha-devil maybe?
i get the feeling both merchants and consumers are going to root around in the hype for a while and then just turn their backs on this.
slashdotters will hate them anyway because they obviously use windows in the office.
This Like That - fun with words!
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.
This micro-payment system is presumably based on their work :
Silvio Micali and Ronald Rivest. Micropayments revisited. In Bart Preneel, editor, Progress in Cryptology --- CT-RSA 2002, volume 2271 of Lecture Notes in Computer Science. Springer-Verlag, February 18-22 2002.
Here clients are only billed based on what they buy during a certain period of time. Clients do not need to "pre-fill" their account with, say, $10.
It's a nice idea, and shows that there is still a lot of original thinking on micropayments.
I especially like the anonymity.
However, one issue is all the tokens 'out in the wild' - available for crackers to bang away at. If someone works out how to forge a winning token, Peppercoin is toast, as is the scheme. This is the problem with all encryptuion based replacements for cash - they are brittle in security terms. While it is not known if there are mechanisms to break any of the encryption schemes proposed for digital cash, if digital cash becomes accepted, there would be an *enormous* incentive to break those schemes. Mafia Mathematics PhDs anyone?
All such schemes should use multiple, *different* layers of security, so that if one is compromised you have time (relying on the other methods) to remove the compromised tokens from the system.
It's still a nice idea, and if, say, Amazon, took the scheme on board it could even achieve critical mass.
Scaredy Cat
I remember back in the day when a certain OS used random to decide which thread got to run. That scheduler was based on similar logic to peppercoin's: It will all even out on the large scale. The problem was, some things required it to even out on the small scale and some important services were starving every once in a while (maybe days) and taking the system down.
Also, the article fails to explain why the payments are done randomly. And how the 'random' token is chosen. Without some rational and more precise information, this idea is nutty.
Let's say each time the merchant makes a 50 cent sale, they get a 50 cent cookie back. Then with probability 1/20 it's a live one. If they make a 1 dollar sale, they'll get a live one with probability 1/10 and so on. So actually, there's no need to keep a "value" on the cookie, just whether it's live or not, and peppercorn can simply flip a coin based on the sale value. No bookkeeping on their side.
The merchant does the bookkeeping on his side, by throwing away the duds and collecting on each live cookie. Again, on average, if he's made 20 times a 50 cent sale, 30 times a 1 dollar sale, he should have gotten 1 + 3 live cookies at ten dollars each. But the beauty is that the merch hasn't done a lot of bookkeeping either. Neat!
OK, let's finish, the customer gave teh card number to peppercorn. He makes his purchases, which get processed by peppercorn. They see that this time it was 50 cents, and since they have the credit card number, they'll add this number inside the cookie they send to the merch. If it's a live one, the merch collects 10 dollars directly from the customer's credit card. So does the customer get charged properly? Let's say he's purchased 10x50 cent songs, 3x1 dollar songs, 10x2 dollar songs. That's a total of 28 dollars, so he should have been debited 2.8 times on average for ten dollars. So how many live cookies has he got?
He has 10 cookies live with prob 1/20, 3 cookies live with prob 1/10, 10 cookies live with prob 1/5, so the expected nubmer of live cookies is 10/20 + 3/10 + 10/5 = 2.8, yay!
Neat, I think it could work.
It's going to be patented, so I'm almost certain that we won't see wide adoption.
Let's see - either I use some complicated micropayment thing that means I have to give my creit card number to someone and ends up costing me $0.50 per song or...
I get it for free with no hassel for Kaazaa or sumthing. Sounds like a no brainer to me.
Might work for some other stuff but I wouldn't try selling mp3's like that.
E-gold or Goldmoney are payment systems based on transfers of ownership of real physical gold, denominated by mass. Goldmoney scales down to 0.001g (which is worth just over one US cent at todays wartime-high gold prices) and all the way up to infinity. E-gold scales up likewise to infinity and down further (to about 4/100 of a cent at todays prices), and has an e-silver version if you want to go yet smaller.
At some point, either Peppercoin or the online merchant must charge the credit cards of each customer. Say the product is $1 a piece.
:-)
* If Peppercoin does this for each customer, they have the same problem as the merchants had before: the transaction fee will destroy their profits.
* If the online merchant charges the $10 to only one customer, there are going to be some pretty upset people. 9 people get it for free, and one pays $10?
Unless there is some way to combine these 10 transactions into one, including 10 credit card charges, this makes absolutely no sense.
OTOH, maybe it WILL work. It's a purchasing lottery!
"Got stuck with the $10 bill that time?" Play again! You in?
Xesdeeni
Of course this can work. Just like paypal
Customer creates and account and puts in a minimum amount via credit card. The card is charged. Just like paypal.
The only difference is how the money is paid to the merchant; random digital peppercorns.
Don't ask me why this would be desirable.
This is not much of an insight, but:
I'd say the probability is about 95% that this idea is going nowhere, and 5% that it's worth $10.
at last - someone who can be arsed to do the sums...
The consumer FAQ says that the actual payment is consumer-initiated through the PepperPanel, so that invalidates my cheating scheme described in the parent.
However, I'm sceptical of how popular this can be if it requires the user to install external software to handle the payments with.
How about a PIN-protected mechanism similar to a debit-card which allows you to use your phone number to make a purchase? Thats what a 1-900 number is, in essence, anyway.
I know, I know, security concerns. But if a phone company supports this scheme, it doesn't have to be your real phone number, or even a valid phone number. It could be some random number that's associated with your phone number in the phone company's database. The cellphone companies ought to go crazy with this -- it opens up a LOT of options for internet-enables cellphones, esp. when you add bluetooth to the mix.
Okay, the PIN idea sucks for the internet. But hey, there's gotta be a solution there, too. I know of a few, but there's no room in the margin...
It's supposed to be completely automatic, but actually you have to press this button.
What is revolutionary about this? How are the end customers going to be charged? What if I only buy stuff for $3.. How am I going to pay Peppercoin? By credit card? As a consumer, eventually I will have to take out the credit card anyway...
I see a big marketing problem. If so many allegedly intelligent people on /. can misunderstand the system, how the hell are you going to sell it to Joe Public? And Peppercoin's website is useless on this - it sounds like every other snakeoil.com out there.
Consciousness is an illusion caused by an excess of self consciousness.
The problem with this scheme is that the randomly assigned $10/$0 tokens will not really cause the total payment to a company to "average out" over time, rather a Gaussian distribution will form over time. Some companies will get more money than they deserve and some less. A few will get much more or much less.
as opposed to the dumb article itself. Of course it is still my own spectulation, I am no Ron Rivest. (but I do hope my post could be scored up even though it's posted as anonymous coward)
1. a consumer purchases $10 bucks worth of Peppercoin (let's say 20 of them, 50c each), which is delivered as an encrypted text each. Thus, the consumer cannot tell them apart.
2. one of the peppercoin would decrypt into a valid credit card number which authorizes a $10 transaction on behalf of the consumer, and the rest don't.
3. after the vendor gathers all the coins and decrypts them, 5% of them would turn out to be valid transaction and can be sent through existing creditcard processing lines for direct processing.
This now sounds scary to me since it might actually take off, because
1. there is no extra process that demands real-time online processing except the creditcard system most vendors have already adopted. There is no realtime authentication with Peppercoin server, for example.
2. the consumer will have difficulty to abuse the system since he himself does not know which coin is real and which is not! If he just keeps using the same coins for different purchases, he is risking $10 per coin! Not to say impossible, but the fraud due to this can be kept in control due to large sum factor.
3. the beauty is that it eliminates three party conmunication as most other solutions (digicash, etc) require, and at the same time takes most activities offline, i.e., no need for real time server authentication, which is a big part of the online transaction cost.
Most people are wrong at assuming 1000 transactions is 1000 more expensive than 1 transaction. No. Transaction processing is dirt cheap if it can be done in batch at non-realtime.
The only flaw I see is the vendor could be able to duplicate the coins by saying the consumer submitted them twice. But again, I believe Ron Rivest has his solution to this. Controlling vendor is much easier and better enforced by law than controlling the behavior of an anonymous customer.
Example.
1 million transactions
0,5 EUR per transaction
Fact: Customer always pays 0,5 EUR from one transaction, which subsequently will be charged from his/hers credit card account.
Assumption: A credit card company takes 0,25 EUR fee from handling a bill.
So Peppercoin gets money from the customers for every Peppercoin transaction i.e. 1000000*0,5=500K EUR. But they still have to issue all the bills to the credit card company/ies. So the credit card companies take their cur from processing the bills 1000000*0,25=250K EUR. That leaves 500K-250K=250K EUR to the Peppercoin to take their share and give the rest to the merchants.
Then there is the fuzzy Algrithmus Complicadus and the merchants. The merchants get 1 token for every transaction. 95% of the tokens are worth nothing and 5% of them are worth 10 EUR. So the merchants have 1 million tokens and they get on the average 0,05*1000000*10=500K EUR from the Peppercoin. Can this be true?! Because Peppercoin only had 250K EUR to take their own cut and give to the customers. Peppercoin would end up -250K EUR. HUH!?
I believe that some figures were false in the original article. This scenario is feasible if and only if the ratio is something like 98/2 or 95/5 with 5 EUR token.
I only wonder why would not e-merchant sell items 0,5 EUR a piece and take the 0,25 EUR income directly without any intermediary? (OK this holds only with the assumption that the credit card companies charge 0,25 EUR for handling the bill.) I do not see any extra benefit from this Peppercoin system to the merchants.
Peace man/woman.
Why stop with randomizing individual transactions?
Why not just randomize *all* payments for a particular supplier? Either they get paid by Peppercoin that month, or not. Better yet, Peppercoin can randomize their entire set of payments. Either: "Hooray! Peppercoin paid all its bills this year!" or "Sorry. We went bankrupt."
Until I see otherwise, I expect the latter.
J'aime mieux les méchants que les imbéciles, parce qu'ils se reposent. -- Alexandre Dumas
Here is the original presentation on the topic: Peppercorn Micropayments via Better Lottery Tickets by Rivest which gives some more details.
Did you mount a military-grade, variable-focus MASER on an unlicensed artificial intelligence?
Every time you "buy" something, you take a chance on paying some pre-set minimal fee (looks like [US]$10.00). If all you buy is $0.50 items, your chance will be 5% each time you buy. In the long run, it should even out...
BUT...
Realistically, Rivest is making a very conceited assumption; that everyone will be using his micropayment service. The more services, the harder it is to hit that "long run" point where everything evens out. And guess what?
Banking systems ALWAYS err to the benefit of the bank. (Surprise!) They will never allow themselves to come up short. The most likely implementation will bill you the very first time you use it and then give you the random chance.
So, how many Rivest-ish micropayment services would you give your credit card info to? (Did he think he was the only one who could do it?) ...and how much opportunity do you think
this provides for credit fraud, since you never really
know whether you should have been charged
or not.
HOW 'BOUT A SERVICE THAT JUST ADDS UP MICROPAYMENTS AND BILLS YOU WHEN THEY HIT A LIMIT LIKE $10.00? Does anyone remember "NetCash"? They could even ask you to pay the first $10 in advance once they were popular enough. PayPal is already in a good position to implement this... but they don't.
Chances are they've looked into it and figured it wasn't going to be profitable.
-Rick
Coolest ... name ... ever
BUT, not anytime soon, and you've identified the exact reason why: peppercoin patent monopoly. No reasonable merchant nor consumer should bet on a scheme that locks you into one vendor, especially for something as vital as your very revenue source. We like money because it is 100% transferable -- I can get it from anyone willing to trade with me. Credit cards are also competitive -- if I don't like Visa, I can try AmEx or Discover or MasterCard, and most vendor's have a single machine that can take any of the above. If I don't like peppercoin, there's no alternative I can switch out for -- the system is closed, patented, and sealed. Sure, there are other micropayment schemes that have lived and died, but if I wanted to start a peppercoin-compatible service, tough luck; it'll be at least 17 years before we get a legal shot at that.
the article is a little contradictory.
...at the microprices made possible by his software, Rivest figures millions of us will be happy to let him throw our money away.
... not sure if I should be happy that lots of cheap things will be available to buy, given that they were free before.
Many of these goodies will be items that are presently given away, because there's no efficient way to charge for them
So
-- p
Unlike many of the previous posters, I think this method is entirely unsuitable for vendors/providers who have infrequent small sales. When dealing with rare events, the variability of the random distribution can dominate, so that mean behavior tends not to hold. Larger merchants are more likely. However, per-packet charging is unlikely, since the tokens will need to be sent frequently`, they will tend to increase the amount of traffic, by augmenting the payload or by imposing a new layer in the protocol (which just pushes it into a header/trailer).
...Ron find an use for his "Hot Geeks of Course 6" collection.
The white paper describing how they actually track when to fire off a "token payment" should be interesting to read, as far as how far RSA techonology is involved with the solution.
They imply on their web site that they do not randomly bill the customer. That makes sense - if the customer buys only a $0.50 thingy, they would complain about getting a $10 bill to their credit card. So, instead of pissing off the customer, I would guess that PepperCoin hopes that most customers will make many purchases and have only a single credit card transaction for overhead, and then if a small number of customers make single purchases that credit card transaction cost can be buried. Thus, at the paying customer side of the transaction, all purchases are counted and aggragated. PepperCoin has to deal with the full number of transactions, but they only have to pay the credit card company one per-transaction charge because they aggragate them together.
So, what is the point of the random discard?
The selling companies are going to have far fewer cases with only a single transaction per month - and those companies can be billed extra. (So, if you accept PepperCoins at your garage sale, you'll pay a higher premium than an online music seller.)
If PepperCoin can afford to aggragate the transactions on the customer side, then they should have far less trouble aggragating the transactions on the vendor side. Just offer a sliding scale of service charge (maybe something like 50 cents base + 5 cents per transaction being redeemed in the aggragate collection) and let the vendor choose how often to collect their money. When a vendor only colls weekly or monthly, PepperCoin would make interest from the money already collected from the customer.
The only benefit I see for the random discard is that they can patent it.
There certainly is a great deal of value in having a secure encryption technique being used to protect the PepperCoins - and having a reputation like Rivest's behind it is very important in making it creditable.
Based on their FAQ:
[...] launch the PepperPanel viewer and sign in with your user name and password [...]
At least Paypal do not need an applet and is usable whatever browser you use.
I only hope this applet will be Java based and not an IE-specific stuff.
http://www.transparency.org
At least not until it hits some critical mass.
Only by hooking up with PayPal or some other company that instantly lets its customers use Peppercoin will they get the huge userbase they need to entice merchants.
Who wants to offer merchandise to a possible customer base in the mere thousands, most of whom will never find your site on the 'net and even if they do won't be interested?
It seems like the advantage Peppercoin offers is that it's easier for the merchant to process. I imagine that the merchant uses regular credit card clearing to get paid for the $10 tokens, meaning they don't have to add any new external interfaces to their business process. Of course, they still need to significantly update their internal processes in order to go from 100 tokens with an average value of $.10 to approximately 1 credit card transaction with a value of $10.
I believe Classical.com does not penalize for small purchases - how, I don't know.
Reading through the 3+ scored comments here, I don't think anyone really has a solid idea of what is going on here. But I think I might have some insight as to what is really going on.
The problem with doing micropurchases perhaps isn't so much a hard per-transaction fee, but a commission percentage charged by the CC processors. (In other words, the processors are using statistics in order to come up with their flat % rate charged to each transaction.)
I *think* what he might be trying to do here is to use large $$ transactions in order to get small $$ transactions passed through, but without being dropped to a higher % rate. (If you have a lot of $1 transactions, your CC processor will want to bump you up to a higher % rate per transaction, for ALL transactions.)
Of course, this seems like averaging on top of averaging, which the CC processors will eventually see through if it doesn't allow them to make the margins they want (because you're manipulating their statistics as close as you can with a ratio of low-to-high $$ transactions).
Does this make any sense to anyone, or am I way off in left field here?
Some points I assumed (but I might as well right). This system is only useful if it handles big and small transactions. The big $$ transactions are what allows you to get away with a certain percentage of the small $$ transactions. If the number of big $$ transactions isn't high enough, then you'd have to either queue up or start throwing away the low $$ transactions. (Or apply other rules, as discussed, like summing up individual transactions for a particular person until they reach a certain $$ threshold.)
The entire token side is a little strange. But basically, it would seem, for those with small $$ transactions, for a large number of small transactions, they'd effectively be paid a percentage of the amount charged. The high $$ transactions wouldn't use the token system since they would always go through.
All the pondering about "how" this will actually be done has included statistics of some sort. It feels like that word is simply used because the company used it.
The only way to guarantee each merchant recieves his due (and I promise noone will sign up if they're not made that guarantee), is to keep track of how many transactions were made to him. This has absolutely nothing to do with statistics, it's just an accumulator.
1-2-3-4-5 - You get money now!
1-2-3-4-5 - You get money now!
Where'd the statistics go? Saying something happens 10% of the time doesn't mean it took statistics to implement it.
As I see it, the biggest problem in micropayment is the large amout of time each user has to spend by deciding if a certain page is worth clicking, and the technical means that require plugins or other stuff. I highly suggest everybody to read Clay Shirky's The Case Against Micropayments for more infos about the problems micropayments have today.
In addition to the patent/vendor lock-in issues (which are very serious), there's also the risk that consumers will still buy very little stuff. If my assumptions are accurate, if a consumer only buys one or two songs a month, Peppercorn is screwed instead of the merchant.
The only ways this makes a lot of sense is if 1)Peppercorn enlists a wide, broad base of merchants providing heterogeneous services (i.e., if I don't want to pay $10 to eMusic, than I don't plan on spending $10 on song downloads, but I might spend $10 on songs, news, games, etc. combined) or 2) Peppercorn requires some minimum monthly investment, which gets you right back to the subscription model.
After researching past failed efforts for a business plan competition, I came to the conclusion that the problem with Micropayments has never been the technology or payment method behind them. There have actually been multiple plans that did just fine in those areas.
The failure is summed in one word, MOMENTUM. Micropayment companies can't get any because they usually sign up one or two bigger names (those sites have to have *really* compelling content for anyone to sign up), people go elsewhere when they see their favorite little diversion now requires payment, and the micropayment start-up runs out of money before they get momentum. In addition to that, people prefer subscriptions to micropayments.
I do think there is a way to solve the problem, but Peppercoin doesn't seem to be it.
Boom Shanka
Visa/MC competitive?
Courts will ultimately decide this one:
antitrust suit info
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.
As other replies state, this is pretty unlikely, but it can happen. This is similar to the problem of converting an image to a 2-color bitmap, except that it's easier to see the statistical anomolies there.
If you just convert each pixel independently of the others, at random, you can get areas that have too much of one value, similar to having too much "low value" here. The solution for images is to use error diffusion, each time you convert a pixel, you store up a value indicating how far off you were, and use that to adjust the probability for converting the next one.
This way, every low value you get decreases the probability of the next one.
oh wow, guess that shows me.. bwahaha!
fuck off, dipshit.
...what happens? One fixed point number in a database record is decreased, another is increased, and the fact that this has happened is appended to some logs. Why does it cost 25c? Are they storing this info on punched cards made of gold?
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
Explain to me, o banks, why it costs you $2 to give me money from my own accout? Why it costs you $10 to wire transfer some money from one account to the other? Why it costs $1 to give me a balance statement? Why it's 75c to use your ATM card at anywhere but a supermarket? These are just the costs for consumer-visible transactions; the costs of using a credit card or ATM to the business owner must be similarly padded.
These are database transactions. They happen almost instantly and they consume resources at a tiny fraction of the cost we're being charged. It's electricity being sent over a wire; the marginal cost is so close to zero you need calculus to describe it. This is why micropayments don't work yet, and elaborate schemes like this randomization are even necessary at all. PayPal and similar systems have eliminated these costs, but "real" banks refuse to, because they make an assload of money off of charging for the movement of electrons.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
There are issues of user approval that need to be solved to get this working and Peppercoin (man what a lousy name) is not even close to any of them.
I'm not gonna waste your time with my words since Clay already wrote about it in The Case Against Micropayments
The main problem is that users hate micropayments:
"Why does it matter that users hate micropayments? Because users are the ones with the money, and micropayments do not take user preferences into account.
In particular, users want predictable and simple pricing. Micropayments, meanwhile, waste the users' mental effort in order to conserve cheap resources, by creating many tiny, unpredictable transactions. Micropayments thus create in the mind of the user both anxiety and confusion, characteristics that users have not heretofore been known to actively seek out."
Go ahead and read the article. It explains the problem in better detail and it clearly shows why the problem is conceptual and not technical. Then you can happily get on with your life, without Peppercoin and without micropayments. Cheers.
The concept is designed only for digital content. From the site's Merchange FAQ:
Use the PepperMill to encrypt your digital goods for sale. Part of this process includes associating a price and description with each item.
Publish your encrypted content--we call these new files PepperBoxes--on your Web site. (You can also choose to email PepperBoxes to targeted customers.) Make sure to indicate on your Web site that you accept Peppercoin payments for this content.
All consumers are free to download your content in encrypted PepperBox form; however, only those who pay are allowed access to the content. When the consumer pays for the content an exchange is made--the consumer sends a "PepperCoin" for the sale price, and receives the decryption key.
Peppercoin then processes your transactions by running our patent-pending payment processing protocol. You are paid and the consumer is billed by Peppercoin.
Why not just use a stored-value account shared between a wide group of (potentially) related merchants? I may only want one 50-cent transaction from one site, but if you link together 20 related sites, I might easily spend a $10 minimum transaction. When the payment comes in, hold it in a shared account and retain records of who owns what nickels. No probability games. I can even see this working for some of the major e-commerce service providers as a marketable feature. Of course, it doesn't get back to the non-technical problem with micropayments: users don't want to stop every few minutes to authorize another payment.
It's just like a fascist dictatorship, without the punctual rail service!
50 cents "Coins", 10$ payout. You should "win" 5% of the time. So let's do a little probability check for 500 coins = $250, a *small* amount if we're talking micropayments.
Chances of getting:
Less than half: 0,2%
Less than 60%: 2%
Less than 80%: 18%
Less than 100%: 47% (because of integers, should be 50%)
If you're talking about real micropayment shop, with enough coins to have employees and all, the deviation will be completely negligent.
Kjella
Live today, because you never know what tomorrow brings
Well, it seems that the peppercoin folks will be making their money by subtracting a percentage from the probability that a payment is made (i.e., if the site accepts 100 micropayments with a 50/50 chance of a $10 payment on each, they probably took in enough to payout 1% more than the payment total). There's no reason they can't share this margin with consumers by reducing the chances of a payout in return for sign-up bonuses, etc.
What this means is that a lot of people can get introductory deals where they don't get charged at all on their credit card until they've racked up say $5 in payments, and they get the first dollar's worth free, or however much they figure they can get away with.
Then they can turn to the businesses that accept peppercoins and differentiate between confirmed paid customers (who have dished out enough micropayments to have had their credit card successfully billed) and those who are still introductory, and give a better percentage rate on paid customers, encouraging repeat customers.
In other words, if a not-yet-billed customer dishes you a micropayment, you get a chance of a payout based on their likelihood of paying which is fairly low but definitely nonzero. If a confirmed customer comes you get a much better payout based on the likelihood that they will again pass their billing threshhold of say $10 or whatever amount makes it worthwhile to actually bill them.
Please note that I'm not saying this is how Peppercoin will do it, just that this is how they could solve the initial lump payment problem.
It's also worth noting that it still doesn't solve a different problem, and that is the hesitancy of people to give their credit card number out over the internet at all, particularly for services that have the potential to continue charging you for things (i.e., a peppercoin account is more abusable than a book purchase).
This sounds like it could work. In a way I would miss the free-beer web, but then this will draw a sharp division between the free web and the commerce web, and the free web may flourish again once the free professional competition decides to start charging.
Intriguing ideas. Well, there went my lunch break...
microsoftword.mp3 - it doesn't care that they're not words...
a friend of mine is involved in the mobile market, and they are using a different approach to conduct the same thing - people's phone bills.
essentially if you order a 50c song, you get billed 50c on your monthly mobile bill.
an interesting investigation is to the pay as you go market...technically it would be feasible to deduct 50c off your balance as this is maintained on a server infrastructure...
Something worth noting regarding micro-payments: Remember that each internet transaction also has a fixed overhead cost in terms of bandwidth, hardware and support. This is above and beyond any transaction costs from third parties. I believe Visa usually figures this in the 10 - 12 cent range, and they pro-rate that down considerably with their billions (?) of transactions. This is the reason for the 25 cent fixed fee. A smaller company would have a much larger per-transaction cost. I've always thought that the only the best dynamic for micropayments would be the one that evolved in television. The parallels are striking. TV started by providing free content, generating revenues by forcing people to watch ads. Then cable TV came around, under which a company collects a monthly fee which it then divvies up (as a lump sum) with it's content providers. I'm frankly surprised that TLDs haven't already evolved into pay-for-use "content-channels".
The meek shall inherit the earth, in 3 by 6 plots. - Lazerus Long
So, what's the advantage of the system? Since 9999 out of 10000 tokens is worthless. Just put it into /dev/null. Saving all the paper work. If you take all these micro payment to credit card company, they would charge you for $0.25 each transaction which is a waste of time and money. So by the end of the day, the website owner accumulates around 100 tokens that worths $10 each.
For the Peppercoin, if the company is acting fair and square, they should issue one $0.001 token out of 10000, so theoretically, their book is balance. The one who is gambling is the trader who collects the tokens. As we learn in the statistics class, when the trials tends to infinity..... well, we all gamble, don't we.
Or at least that's how merchants will look at it. Not only do they not have a 50/50 chance of getting paid with each transaction, it is a lot less than that (never mind that the payout is more than the cost of the item). I don't see too many merchants (most of whom probably don't understand statistics) deciding to incorporate a "game of chance" into their business model. Speaking of gambling, as peppercoin (the House) has to make a profit, doesn't it have to "win" (even just a little bit) in the long run? So the odds of a merchant getting paid fully are less than perfect).
Stupid people make stupid things profitable.
This is essentially a very simple idea. The interesting question is how they solved the following problem. Neither the article or (awful) website gives any information. :) Anyone see how it is done?
Let me oversee how this system works...
Lets say a customer wants to purchase 1,000 peppercoins worth $0.05 for $50.00. In return for $50.00 the service sends 1,000 peppercoins. Now, approximately 5 of these 1,000 peppercoins will be worth $10.00 each and the other 995 will be essentially worthless. Certainly it should be impossible for the customer to separate the 'good' from the 'bad' (if the customer could pick out the 'good' peppercoins he would cash them in himself). On the other hand the merchant must then not be able to tell the difference between 'good' and 'bad' peppercoins (if he could he would sell this ability to customers for a nifty fee). Thus only the service can reliably distinguish between 'good' and 'bad' peppercoins. Thus each of the 1,000 peppercoins the customer purchases must go back to peppercoin for 'sorting' and the service must take action on each of these individually.
At this point I see absolutely no advantage in the probabilistic marking of peppercoins since the service has to make a transaction for each of the peppercoins. They might as well then treat every peppercoin as worth $0.05 and debit and credit customers and merchants as appropriate. I don't see a way that probabilistic marking will dramatically reduce the processing done per transaction by the peppercoin service, but then again I am not Ron Rivest.
There are two problems with micro payments: 1) The processing cost of the seller. This solves that problem. 2) The decision cost of the buyer. When buying online you are buying sight unseen. low cost items are generally impulse buys, which tend not to happen sight unseen. It also makes a LOT more sense to sign up with a single specific trusted company for sight unseen stuff then to purchase from tons of others.
excitingthingstodo.blogspot.com
Nobody needs to patent that--my current bank already does that kind of random charging (I leave it up to interpretation whether that's deliberate or accidental). But at least, if I scream enough at them, then can at least in principle track down the payment.
We have a good solution for micropayments: digital cash. The merchants should be able to reduce their transaction costs as much as they like by batching their deposits. An even simpler solution is what PayPal and c2it did/does: they keep an on-line running total an only charge the credit card once. It seems to me that if we need anything else, it's a marketing problem, not a technological problem.
>Why stop with randomizing individual
>transactions?
If checks aren't put in place, what stops the
highly improbable, but possible outcomes from working against a given merchant?
Maybe they have a good idea here... I have no idea because they don't explain it. Here are the in-depth details of how payments work:
Browse the Web and download items you wish to purchase. (The Web site will indicate what content you can buy with Peppercoin). To pay for items, launch the PepperPanel viewer and sign in with your user name and password.
The PepperPanel will display price and other information about the content. You will be given the choice to Open or Save the file. Either option will generate payment to the content owner.
You will be billed for purchases by Peppercoin to the payment instrument used in establishing your account.
Notice how they leave out everything we'd want to actually *know*. And, uh, save or open the *file*? What's this file? Obviously, I want to know WHEN I will be billed. Prepay vs. Postpay? Is that not a freq. asked question, somehow?
I'm also missing the point of the randomness, except for skimming purposes. Where's the extra work in keep track of an exact balance? One number in the database per customer and per merchant, and settle each account at the end of each month. There's no reason they'd have to be whole numbers; that's not what the cc companies care about.
--
Einstein: Everything should be made as simple as possible, but not simpler.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
Ahh, remember the dot-com bubble?
New CEO: "We estimate that we will lose money on 95% of our transactions."
Venture Capitalist: "Then how will you make money?"
New CEO: "We'll make it up in volume!"
-- I have monkeys in my pants.
Doesn't the statistical payoff factor make this gambling under some state and local laws?
http://theory.lcs.mit.edu/~rivest/MicaliRivest-Mic ropaymentsRevisited.ppt
This is an alternative micropayments system, where the consumers don't pay for content, but rather are shown advertising, in a model analagous to free-to-air radio and TV.
http://www.pico-pay.com/
They should take a note from Nintendo...
"Be there in a sec, I just gotta blast these MicroPayments to get the gold Peppercoin..."
evolution IS god.
Why does their logo look so much like Blender's logo?
Perl 6 will give you the big knob. -- Larry Wall
The article is very misleading. Rivest has a paper on his website on a couple micro-payment schemes (I assume one of these is the basis for Peppercoin) that clears up the confusion.
Here are two schemes in the paper:
Scheme 1
- The Customer buys something from the Merchant.
- The Merchant is issued a P-Coin which is payable with probablity S (if payable, the coin is worth 1/S cents).
- If the coin is payable, when the Merchant redeams it his account is credited with 1/S Cents and the Customer is charged 1/S cents (over time the customer's payments and purchases balance).
Scheme 2The problem with Scheme 1 is the possibility of a customer overpaying. Scheme 2 solves this by shifting the risk (not really a risk, it all balances out over many transactions) of overpayment to the bank (in this case Peppercoin Co.). You are assured that you will never be charged more than you spend.
The key point is that only a small number of transactions are processed (from both the merchant's and customer's point of view) thus cutting costs.
Why the need for randomness? If Peppercoin just kept track of every transaction and paid the merchant in aggregate, it would still need to do a bunch of small transactions to charge the individual credit cards.
Why not just do the credit card transactions in aggregate (at the end of each month, say)? I'm not sure about this one. Maybe because the math is too uncomplicated if you do it that way.
Everyone else is chiming in so why not me?
1) How this is different.
As I see it this only works if it randomizes both the purchaser and the seller. Here's why.
The main problem with micropayment systems is that recordkeeping costs money. Peppercoin can't aggregate the payments for a month and bill you at the end of the month, because that creates a recordkeeping burden that makes their system cost just as much as any other.
2) How to ensure true fair coinflips?
There are ways to do this with a little clever algebra... Basically what happens is that each person contributes some data, the data gets combined in a way that no-one can pre-compute the outcome, and the result is a fair uniform distributed random number.
3) The standard deviation
Basically what we're talking about is a binomial distribution of payments. Let's use the example given: probability of payment is 1/10, payment amount is $10, and price of good is $1. In the average everything works out.
Now here's the catch. The average will come out right, but if these are independent events (no covariance) then the variance of the sum is the sum of the variances. so your risk is growing linearly with the number of transactions! So for 1 million businesses each doing 1 million dollars in business, there are a few who would not get paid more than say $100k
!!!
gotta go, but someone check my math here!
((lambda (x) (x x)) (lambda (x) (x x))) http://www.endpointcomputing.com a scientific approach to custom computing.
Implemented ages ago, in the public domain.
Monte Carlo pledge fulfillment for the Buskpay microdonation system.
That and any merchant that is selling anything for so cheap doesn't accept credit cards, they only take paypal.
Good security is based upon reality and common sense. Common sense is a function of having common knowledge.
You have to read the Conference Paper to see that it is only when one of the user's transactions actually reaches the bank (Peppercoin) that the bank figures out from the jump in SERIAL NUMBERS how many peppercoins the user has used. At THAT point his credit card is charged for ACTUAL USE.
M ic ropaymentsRevisited.ppt
Only 1 in a thousand of the peppercoins being used actually returns to the bank, thus lowering overall transaction fees to the merchants. Hence cheaper than PayPal type systems that must process every charge. User sees no statistical risk. Vendor's volumn is so large he sees a very small margin of error.
http://theory.lcs.mit.edu/~rivest/MicaliRivest-
Sorry I can't prevent space in that URL
Another micropayments SCAM......
Simple Simon met a pieman,
Going to the fair;
Says Simple Simon to the pieman,
"Let me taste your ware."
Says the pieman to Simple Simon,
"Show me first your penny,"
Says Simple Simon to the pieman,
"Indeed, I have not any."
In this period, pieman sold pies for a penny. Well, sort of - in fact, what they did was ask to see your penny. Then they'd toss you for it. If they won, they got the penny (and you got no pie), if you won, you got the pie and the penny.
This sounds pretty much the same technique to me - except the price of the penny is half a penny. You always get the pie, but the pieman may or may not be paid.
"Cats like plain crisps"
(Hey, that's the second one this week!)
p m- 3.3.1/doc/TCDevGuide.html#wallet
Micropayments for retailers:
http://search.cpan.org/src/TRUSTCOM/Net_TCLink.
This is actually the opposite of the solution proposed in the article; it enables the merchant to handle micropayments, instead of allowing the customer to pay them.
At least that's how I think it works. Of course, there's the whole question of trust, which could make or break the scheme.
I have completely different idea for micropayments.
/12 = 0.15% * $7 = 1c !!!
...
Howeve I do not know how charging credit cards works.
If card is charged but if after the month
item is returned, does the merchant
get full refund from VISA/Mastercard ?
If so - my idea is such:
For evey cent spent on micropayment
the merchant charges 7 dollars and then
returns them after the month.
Merchant does not pay anything to VISA.
But keeping $6 for a month is worth
$7 *1.8%
So merhcant makes micromany on short term
microloans!!!
It is a good buisness for both merchant and
the consumer - merchants get cheap credit.
Consumers, when they use CC with longer
grace periods pay nothing.
Only VISA/Mastercard looses money.
I guess it is too sweat to be true
Thank god that patents require full disclosure: it'll be nice to be told what the hell they're talking about in something other than marketing-speak FAQs... Seriously: they don't seem to have the consumer-side of the equation all fleshed out. Visa won't be too happy if I start charging micropayments to my card whether the merchant randomly gets the money or not. Are they going to be using the same probability trick for consumers? Are they going to be aggregating purchases? Are they going to use accounts like PayPal? Come on, Rivest, fess up!
Bray is moron. Anyone who thinks they might learn something from reading one of his articles will be sorely disappointed. Better to go the the horse's mouth for a keener explanation.
A passion for apathy.
In this case, he's covering the innovation of someone who is fairly smart.
For a more indepth look at these systems, check out: http://theory.lcs.mit.edu/~rivest/MicaliRivest-Mi
As for other points raised here: The idea behind many small transactions being lumped together into a larger one makes this a feasable system to use when the cost per transaction (to credit the merchant) matters.
Consumers will be shielded from the statistics - the idea is their bank / the micropayment provider makes up the differences, absorbing the swings themselves (but having them dampered by the large sample size).
If you have mathmatical questions as to this scheme, read the paper - it's very complete (if a bit dense)
Rivest has published some more micropayment scheme before this one. One of them is called Payword . Payword allows certified customers to generate electronic coins themselves. Vendor can validate this coin by using the digital signature provided by the Bank. By doing this way, the real-time network communication between customersbank to buy/sell electronic coins is minimized which is always a bottleneck to many coin based scheme.
My final year project is an implementation of the payword scheme. Anyone interested can contact me and I can send you a copy of my report. jonearth@hotmail.com
i think credit card co's had better take a look at this and decide 'Maybe we here at (insert cc company here) should STOP charging a per transaction fee...' Why should there be another layer to making a payment?
When reading the article and FAQs on the Peppercoin site, I kept thinking that it made no sense from the merchant's point of view to throw away most of the transactions instead of verifying them with Peppercoin.
There are 4 point-to-point transactions occurring in the Peppercoin system:
The savings appear to only occur in transaction 3. Let's compare this system to a typical stored-value system like Paypal.
Paypal transactions always have the Customer log in to the Paypal site at some point to verify their identity, as in Transaction 1. With Peppercoin, the code to authorize the transaction seems to be created by the Customer's computer. However, since the customer's account appears to be debited the exact amount of each purchase, there must be communication between the Customer to Peppercoin for each transaction. The system cannot rely on an indirect communication through the merchant for this, since the merchant throws away most ( [10-paymentvalue]/10 *100% ) of the "Peppercoins", and doesn't report them. Peppercoin's central servers must be cryptographically involved in the creation of the Peppercoins to ensure that they are reported.
Transaction 2 is more onerous than a typical Paypal payment, as it requires the Customer to invoke a custom software application to create the Peppercoin.
Transaction 3 is much easier for the merchant. With Peppercoin, on average, they only have to process one transaction for every $10 worth of value received. Using Paypal's "MassPay" system, the merchant must contact Paypal's servers to confirm each transaction.
Transaction 4 is unknown. Peppercoin is vague about the account that customers have with them. Their web site and the article mentioned both imply that the roulette-style banking will not be used here. Quote:
http://www.peppercoin.com/consumer_faq.html
"You will be billed on your credit or charge card for the amount you spend " (emphasis mine)
Not "approximately the amount you spend". This seems to imply that Customers' Peppercoin accounts are simply stored value. Peppercoin will probably make a credit card charge of $10 or so to open an account, and then put another $10 charge through again each time the balance reaches $0. This will avoid a disproportionate amount of any micropayments from being eaten by bank fees.
But to optimize transaction #4, any stored value system could use the same methods. As long as Peppercoin is billing customers for the exact amount they spend, there is nothing new here. Paypal could easily implement the same optimizations.
So the whole point of the system must be to save computational and network resources at the merchant's end for processing each transaction. But the question is why? Exactly what problem are they trying to solve here?
A server to server transaction for a merchant to verify a Paypal payment involves very little network traffic. You need to send over the transaction code, some customer details, and you receive back a result code indicating that the transaction was successful or not.
For argument's sake, take a conservative estimate of 1KB of data flying back and forth per transaction. With today's inexpensive and reliable bandwidth and computing resources, this is very cheap. Put a price of $15 per GB for the bandwidth and a similar amount to lease the CPU cycles, and this costs about 3/100ths of a cent per transaction. So if a Peppercoin merchant has one $10 token to process instead of a twenty little 50 cent transactions, they will save about half a cent, a tiny fraction of the value involved.
For this system to make any sense at all, we must be talking about much smaller micropayments. What if each micropayment was 1/100th of a cent? In this case, the merchant would collect 100,000 payments on average before needing 3/100ths of a cent of resources to connect to Peppercoin servers to redeem a $10 coin. A Paypal merchant would have to make 100,000 http calls, costing them about $30 to collect $10 worth of micropayments.
For Peppercoin to work, the other transactions need to be limited as well. There's no point in saving the Merchant $30 of bandwidth and CPU resources if it cost Peppercoin $30 of resources in transaction #1, Customer to Peppercoin.
Transaction #1, Customer to Peppercoin could be scaled down by allowing some value to be stored on the Customer's system directly. If they could download $10 worth of Peppercoin into their local app, a network transaction would not be necessary for each micropayment. Previous, now-defunct systems have worked out the necessary cryptography to ensure that stored values can only be spent once.
I have a better idea. Put all of the random selection of when to bill at the Customer side, instead of the Merchant side. Take out the requirement of the Customer needing a Peppercoin account. Here's what my system would look like, call it PepperCash:
Of course, we don't want people to enter in invalid credit card information, and let it go through 95% of the time. This could be avoided by the PepperCash servers storing a database record of the payment info of all previous transactions. To prevent security catastrophes, the credit card numbers themselves would not be stored, only an MD5 hash of the numbers.
Every time a transaction is received from a merchant, it is matched against this database. If no match is found, the actual value of the transaction is charged to the credit card, plus 3% and 50 cents to make up for Bank fees. The banking network then verifies that the payment information is valid.
This makes the very first Micropayment made with the system into a kind of signup fee. Depending on how deep the pockets of the Angel Investors are, this extra 3% + 50c fee could be waived.
I release this idea into the public domain. Software patents are bad. :)
Banks keep mum about what their real costs are, so I wouldn't know what they claim--those numbers are what we actually pay. Banks here have also started encouraging overdrafts so they can charge you astronomical interest.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
You open a PepperCoin account.
You can buy some amount of coins with minimum purchase of say 10 dollars at a cost of 50 cents a coin. PepperCoin will charge you for the coins then in one lump sum.
Now you go shopping and spend the coins like real money. Some coins are worthless, some are worth 10 dollars. Neither you or the merchant knows at the time you spend the money.
PC collects all the coins deposited by the merchant and examines them. The merchant is paid 10 dollars minus some fees.
I don't see how this is much more beneficial that how other cybercash systems worked though.
If it is more like the Russian Roulette algorithm where sometimes you get charged 10 bucks and sometimes you don't then I think it will fail since many consumers would think of it as gambling.