Micropayments, redux

[Ed Gerck]

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 majordomo at wasabisystems.com


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com