Re: [picoIPO] Re: Micropayments, redux

2002-12-24 Thread R. A. Hettinga

--- begin forwarded text


Status: RO
Subject: Re: [picoIPO] Re: Micropayments, redux
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
To: [EMAIL PROTECTED] (Andrew Odlyzko)
From: Charles Evans [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Date: Wed, 18 Dec 2002 12:56:27 -0500

This message is coming by way of the picoIPO list.  Apologies for any
confusion caused by intercommunication among para-debates.

On Wednesday, Dec 18, 2002, at 08:01 US/Eastern, Andrew Odlyzko wrote:

 Dear Colleagues,

 Just a few general comments on the flurry of messages from
 yesterday.  I certainly do see micropayments playing some
 role in the economy in the future.  I agree that we do have
 the technology to implement them easily.  However, I still
 think that they will play only a marginal role...

The second sentence of the abstract reads, The main concern of this
paper is with pricing of goods that are likely to be consumed in large
quantities by individuals.  The current debate, with regard to
micropayments and microfinance, is like comparing apples and orangutans.

For mass-market goods, the argument in favor of subscription is
compelling, especially in the West/North.  I would not rent time on MS
Word or OS X, even if it were less expensive than buying licenses.
However, in the Third World, where money is very scarce, a la carte is
still very common.

In Ukraine, where typical incomes are USD 200-300 per MONTH, computers
are too expensive for most.  Internet cafés are quite common, and
charge about USD 1 per hour.  A flat USD 20 per month dial-up
subscription is prohibitively expensive, when you add in the per-minute
telephone charges and the cost of the computer, monitor, and modem.

snip

 The basic reason for this prediction is that even in the absence
 of the many behavioral economics factors, producers benefit
 from bundling (as in selling an entire newspaper instead of
 individual articles) by taking advantage of uneven preferences
 among consumers for the individual items...

For large Western/Northern software and entertainment producers, yes.
However, in the Third World -- the other 5.5 billion -- the economies
of scale are different.  For the price of a full license of MS Office,
a family can live for a month or two.

Building a viable business model out of this observation, and
implementing it are separate matters.  This is a theoretical discussion
of subscription versus a la carte.

There are markets where a la carte is preferable over subscription.

snip

 Not everything can be shoehorned into the flat-rate subscription
 model, so I do expect that micropayments will eventually play
 a role in the economy, but I don't expect that role to be large.

There is large and there is large.  But your point is correct.  We
economists do not like corner solutions, and one-size-fits-all
solutions generally neither fit nor solve.

CE

___
picoIPO mailing list
[EMAIL PROTECTED]
http://lists.picoipo.com/mailman/listinfo/picoipo

--- end forwarded text


-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: Micropayments, redux

2002-12-17 Thread John R. Levine
 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.

I believe that both of these sentences are true, but I don't see any
obvious connection between them.  Micropayments have two problems.
The minor one is that technically we have no idea how to implement
them.  The major one is that users hate the idea.  Look at Andy
Odlyzko's work on pricing of communications, and you'll find that the
trend has always been away from nickel and dime per unit charges
toward flat rate subscriptions.  That's why all of us cell phone users
and dialup Internet users have plans with bundles of service, even
though it'd usually be cheaper on average to go a la carte.

For all I know, in a world where lots of people wanted to make lots of
tiny payments, Peppercoin would work.  But is there any reason to
belive that world is this world?



-- 
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869
[EMAIL PROTECTED], Village Trustee and Sewer Commissioner, http://iecc.com/johnl, 
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: Micropayments, redux

2002-12-17 Thread Anton Stiglic
  Yes, but the probability of it being significantly worse than I claimed
  (i.e., by more than a factor t) is exponentially small (in t).  One can
  easily calculate concretely exactly what the risk curve looks like.
  I'll spare everyone the details and just say that I see no reason why
  this should be a showstopper in practice.
 
 Actually I think it may be a showstopper in practice for rather 
 different reasons -- people's behaviour when exposed to risks is rather 
 odd.  

There is no risk for the user in the new schemes (which is what Peppercoin
is developing)!

Read the paper and/or presentation Zulfikar referenced in his post.
The risk is for the Bank.

--Anton


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Plug (was Re: Micropayments, redux)

2002-12-17 Thread R. A. Hettinga
At 12:55 AM -0500 on 12/17/02, John R. Levine wrote:


 Micropayments have two problems.
 The minor one is that technically we have no idea how to implement
 them.  The major one is that users hate the idea.

Oddly enough, and speaking of the Financial Cryptography conference :-),
Nicko's running a panel this year:

http://ifca.ai/fc03/index.php?page=schedule

...

Monday, 27-Jan-2003

...

14:00 - 15:30 Panel: Does anyone really need MicroPayments?
Moderator: Nicko van Someren (nCipher)
Participants: Bob Hettinga (IBUC), Andrew Odlyzko (University of
Minnesota) and Ron Rivest (MIT, PepperCoin)
Many cryptographers have tried to develop special technology for
transferring tiny amounts of value; the theory being that the computational
and/or administrative costs of other payment schemes render them unsuitable
for small value transactions. In this panel we will discuss two major
questions: firstly are the existing systems really not useful for small
values and secondly might other models such as flat rate or subscription
systems be more suitable anyway, and be possible without the need for small
payments?

By the way, statistical process control is nothing new, and probabilistic
settlement is one of the first things they teach you in elementary
economics classes to explain the use of statistics -- railroads billing
each other statistically for boxcar hauling by sampling bills of lading,=
as the canonical example.

Cheers,
RAH
Who, having just seen who else Nicko's put the panel, can't wait to see
Andrew and Ron discuss, um, things in light of the the list traffic this
morning...
-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: Micropayments, redux

2002-12-16 Thread R. A. Hettinga
As I've said here before...

At 6:51 PM +0530 on 12/16/02, Udhay Shankar N wrote:


 Peppercoin is

...Ron Rivest's random-settlement lottery payment protocol.

Essentially, you write 10 checks for $100.00, and redeem one of
them, yielding an expected payment of a tenth of a penny.

You need very strong is-a-person digital signature credentialling,
just like checks. It's quite compatible with PayPal, etc., and so I
expect that that's part of their exit strategy.

If they could get plugged into the ACH/ATM network, it might work
there as well, so you could also sell it to banks, if they're buying.

Cheers,
RAH


-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: Micropayments, redux

2002-12-16 Thread 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 [EMAIL PROTECTED]


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: Micropayments, redux

2002-12-16 Thread Ed Gerck
David:

I'm happy you don't see any problems and I don't see
them either -- within the constraints I mentioned. But
if you work outside those #1, #2 and #3 constraints
you would have problems, which is something you may
want to look further into.

For example, in reply to my constraint  #2, you say:

 This is expected to be roughly counterbalanced by the
 number of unlucky users who quite (sic) while behind.

but these events occur under different models. If there
is no prepayment (which is my point #2) then many users
can quit after few transactions and there is no statistical
barrier to limit this behavior. On the other hand, the number
of users who quit after being unlucky is a matter of statistics.
These are apples and speedboats. You ned to have an
implementation barrier to handle #2.

Cheers,
Ed Gerck


David Wagner wrote:

 Ed Gerck  wrote:
 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.

 I think you misunderstand the nature of the martingale strategy.
 It's not a good way to win in Las Vegas, and it's not a good way to
 win here, either.  Anyway, even if it were a problem, there would
 be lots of ways to prevent this strategy in a digital cash system.

 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.

 No problem.  This is expected to be roughly counterbalanced by the
 number of unlucky users who quite while behind.

 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.
 [...] The problem here
 is that, all things being fair, the system depends on
 unlimited time to average things out.

 No, it doesn't.  It doesn't take unlimited time for lottery-based
 payment schemes to average out; finite time suffices to get the
 schemes to average out to within any desired error ratio.  The
 expected risk-to-revenue ratio goes down like 1/sqrt(N), where N
 is the number of transactions.  Consequently, it's easy for banks
 to ensure that the system will adequately protect their interests.

 And everything is eminently predictable.  Suppose the banks expect
 to do a 10^8 transactions, each worth $0.01.  Then their expected
 intake is $1 million, plus or minus maybe $1000 or so (the latter
 depends slightly on the exact parameter choices).  Any rational
 bank ought to be willing to absorb a few thousand in plus or minus,
 at this level of business.

 In short: I think your list of problems in the approach are not
 actually problematic in practice.

 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: Micropayments, redux

2002-12-16 Thread David Wagner
Ed Gerck  wrote:
For example, in reply to my constraint  #2, you say:

 This is expected to be roughly counterbalanced by the
 number of unlucky users who quite (sic) while behind.

but these events occur under different models. If there
is no prepayment (which is my point #2) then many users
can quit after few transactions and there is no statistical
barrier to limit this behavior.

Yes, that's true.  Still, the loss is bounded, even if there is no
prepayment.  Suppose that each transaction is for 1cent, and we set things
up so you pay 1/100 of the time.  Then the most any given user can walk
off by quitting early is about $1.  The costs of customer acquisition
are probably far greater than $1.  For instance, many online payment
schemes were offering $10 coupons just for signing up to the system.

Remember also that this scheme requires strong is-a-person credentials,
so each person can probably pay this game at most once.  This means
there is not much incentive for anyone to bother trying to game the
system on purpose.  And, as you say, it is not hard to tweak the system
to reduce the amount the bank can lose in this way, if you care.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: Micropayments, redux

2002-12-16 Thread Matt Crawford
 No, it doesn't.  It doesn't take unlimited time for lottery-based
 payment schemes to average out; finite time suffices to get the
 schemes to average out to within any desired error ratio.

Strictly speaking, the average will come within your error tolerance
of the expected value *with probability near 1*.  In an infinite
number of trials, it will come within your tolerance *with
probability 1*.  Neither case is a guarantee that it will come that
close to the expected value.

 The expected risk-to-revenue ratio goes down like 1/sqrt(N), where
 N is the number of transactions.  Consequently, it's easy for banks
 to ensure that the system will adequately protect their interests.

Expected, yes.  But the absolute upper bound on loss does not.

These quibbles may be of interest only to mathematicians and insurers.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: Micropayments, redux

2002-12-16 Thread R. A. Hettinga
At 6:23 PM -0600 on 12/16/02, Matt Crawford wrote:


 These quibbles may be of interest only to mathematicians and insurers.

...and thus underwriters of the financial instruments in question? :-).

Cheers,
RAH
That's why they call it *financial* crypto, boys and girls...
...Though the accountants *do* have this thing called 'materiality'...
...Right, and that's also why some people say that finance is accounting
with real math. Okay, mathematical economics...
:-)
-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: Micropayments, redux

2002-12-16 Thread David Wagner
Matt Crawford  wrote:
 No, it doesn't.  It doesn't take unlimited time for lottery-based
 payment schemes to average out; finite time suffices to get the
 schemes to average out to within any desired error ratio.

Strictly speaking, the average will come within your error tolerance
of the expected value *with probability near 1*.

Yes, but the probability of it being significantly worse than I claimed
(i.e., by more than a factor t) is exponentially small (in t).  One can
easily calculate concretely exactly what the risk curve looks like.
I'll spare everyone the details and just say that I see no reason why
this should be a showstopper in practice.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



RE: Micropayments, redux

2002-12-16 Thread Zully Ramzan
There are a number of ways to deal with some of the objections that have
come up in this thread; e.g. the unlucky user scenario. 

Refer to the paper Micropayments Revisited written by Silvio Micali
and Ron Rivest:  
http://theory.lcs.mit.edu/~rivest/publications.html

[The powerpoint slides are also quite useful.]

The schemes in this paper combine Payword (Rivest and Shamir) with the
Lottery Ticket proposal (Rivest).  They also introduce a number of other
neat ideas.  As of the last time I talked to Ron and Silvio about it,
the Peppercoin scheme is based on these techniques.   

Regards,

Zully   

~
Zulfikar Ramzan
IP Dynamics, Inc.   http://www.ipdynamics.com
Secure, Scalable Virtual Community Networks
 

 -Original Message-
 From: David Wagner [mailto:[EMAIL PROTECTED]]
 Sent: Monday, December 16, 2002 4:47 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Micropayments, redux
 
 Matt Crawford  wrote:
  No, it doesn't.  It doesn't take unlimited time for lottery-based
  payment schemes to average out; finite time suffices to get the
  schemes to average out to within any desired error ratio.
 
 Strictly speaking, the average will come within your error tolerance
 of the expected value *with probability near 1*.
 
 Yes, but the probability of it being significantly worse than I
claimed
 (i.e., by more than a factor t) is exponentially small (in t).  One
can
 easily calculate concretely exactly what the risk curve looks like.
 I'll spare everyone the details and just say that I see no reason why
 this should be a showstopper in practice.
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to
[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: Micropayments, redux

2002-12-16 Thread Andrew Odlyzko
The Micali-Rivest Peppercoin scheme http://www.peppercoin.com
seems awfully hard to distinguish from an instance of the
probabilistic polling scheme invented by S. Jarecki and myself,
which was presented at the first Financial Cryptography conference
in 1997, published in Financial Cryptography, R. Hirschfeld, ed., 
Lecture Notes in Computer Science #1318, Springer, 1997, pp. 173-191, 
and is available online at

   http://www.dtc.umn.edu/~odlyzko/doc/polling.pdf

and

   http://www.dtc.umn.edu/~odlyzko/doc/polling.ps.

(This scheme is also covered by US patent #5,999,919.)

Andrew

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]