What follows below is from my dialogue with Ron earlier this year, when the design was still being worked out as he told me, when he kindly answered some of my remarks -- which I also report below.
This is a very interesting proposal that creates a large aggregate value worth billing for (in terms of all operational and overhead costs), but which large value the user will pay *on average*. The user has a limit, and one idea is that the user would pre-pay it (which may raise questions about creating a barrier against spontaneous buying but could be presented as an authorized credit limit, I think) and then spend the limit in thousands (or more) of "peppercorn-worth" (i.e., very small value -- maybe cents or fractions of cents) transactions that would be paid only *on average*. That is, most of the peppercorn transactions would go *unpaid* and *unprocessed* -- thus, with near zero overhead. However, some transactions would hit the "jackpot" and be charged with a multiplicative factor that -- on average -- pays for all unpaid transactions and overhead. Thus, because of the limit and the prepay, this can be seen as a game that has no possible underpaying strategy for the user, and the bank would be happy to let the user play it as often as he likes -- with the following caveats: 1. If there is no limit, then the well-known doubling strategy would allow the user to, eventually, make the bank lose -- the user getting a net profit. 2. If there is no prepaid amount, lucky users could quit "while ahead" -- which would hurt the bank since those users would be out of the pool to be charged, but they have used the service. 3. The game is fair -- the bank will not "weigh the wheel" (and hurt the users) and no one can compromise the methods used by the bank (and hurt the bank). Of course, if the wheel is not exactly balanced, or if the house takes a cut in some other way, then the user or the bank are losing ground at each step. Another question, which answer I guess is more market-related than crypto-related, is whether banks will accept the liability of a losing streak ...for them. Likewise, users may lack motivation to continue using the system if they have a losing streak (i.e., if they run out of their prepaid amount sooner than what they and the bank expects, and pre-pay again, and again run out of money sooner than expected, and again until they give up to be on the losing side). The problem here is that, all things being fair, the system depends on unlimited time to average things out. This can be compensated, I'd expect, by adequate human monitoring and insurance. As always, it is not only the math that makes things work -- even though it's also the math. All things considered, though, as I said above this is a very interesting proposal because it does reduce processing and overhead costs to near zero for a large number of transactions. I'd refrain from saying "zero" because there should be some auditing involved for all transactions. Cheers, Ed Gerck Udhay Shankar N wrote: > Ron Rivest is involved, too. Anybody got more info? > > http://www.peppercoin.com/peppercoin_is.html > > Peppercoin is a new approach to an old challenge: how to make small value > transactions—micropayments—feasible. There is a whole world of digital > content gathering dust because owners cannot find a profitable way to get > it into the hands of paying customers. > > Merchants can profitably sell content or services at very low price points, > which would be unprofitable with traditional payment methods. > Consumers can purchase small-value items easily; PepperCoins are "digital > pocket change" for music, games, and other downloads. > > Through a cryptographically secure process of sampling digital payments, > Peppercoin reduces the volume of transactions processed by a third-party > payment processor or financial institution. Peppercoin utilizes the most > robust and secure digital encryption technologies, based on RSA digital > signatures, to process and protect payments. > > Peppercoin's innovative technology is protected by worldwide patent > applications. > > -- > ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
