Micropayments, redux

Ed Gerck egerck at nma.com
Mon Dec 16 15:53:50 EST 2002


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


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



More information about the cryptography mailing list