Micropayments Revisited
Ronald L. Rivest & Silvio Micali
RSA Conference 2002
Seminar 89-957, CS Dept., Bar Ilan University
By Sharon Haroni
Outline
What
is a micropayment
The need for micropayments
Dimensions in micropayment
approaches
Previous work
New methods: MR1,MR2,MR3
What is a “micropayment”?
A
payment small enough that
processing it is relatively costly.
Note: processing one credit-card
payment costs about 25¢
 A payment in the range 0.1¢ to $10
The need for small payments
 “Pay-per-click”
purchases on Web:
– Streaming music and video
– Information services
 Mobile
commerce
– Geographically based info services
– Gaming
Payment schemes
 Dominant
today:
– Credit cards
– Subscriptions
 Other
possibilities:
– Electronic checks
– Anonymous digital cash
– Micropayments
FOR SALE
Why aren’t micropayments
already here?
 The
market need is still nascent.
 Rolling out a new payment system
requires the coordination of many
players.
 Fundamentally: COST !
Existing micropayment schemes are
too costly to implement.
Payment Framework:
Payment System
Provider (PSP) -
Bank
Authorization
Deposit(s)
Payment(s)
User
Merchant
Dimensions to consider:
 Level
and form of aggregation (for
transactions)
 On-line PSP vs. off-line PSP
 Interactive vs. non-interactive
 Ability to handle disputes
 Ability to handle overspending
 Robustness against fraud
Level of Aggregation
 To
reduce processing costs, many small
micropayments should be aggregated
into fewer macropayments.
 Possible levels of aggregation:
– No aggregation: PSP sees every payment
– Session-level aggregation: aggregate all
payments in one use session
– Global aggregation: Payments can be
aggregated across users
Form of Aggregation
 Deterministic
aggregation:
Accounting is exact.
 Statistical aggregation:
Accounting is statistical
 In MR2 proposal makes aggregation
look deterministic to user but
statistical to bank.
On-line PSP vs. Off-line PSP
 On-line
PSP:
PSP authorizes each payment or each
session.
 Off-line PSP:
User and merchant can initiate session and
transact without participation of PSP.
 Note:
– PSP should be off-line if scheme has global
aggregation.
– If multiple PSP’s involved, off-line is better.
Interactive vs. Non-interactive
 Interactive:
Payment protocol is two-way dialogue
 Non-interactive:
Payment protocol is one-way
Ability to handle disputes
 User
claims he didn’t
approve payment
Solution: use digital signatures
 User claims goods are poor quality or
were never sent.
Solution: let user complain to
merchant directly.
Ability to handle overspending
 User
may refuse to pay
PSP for payments he
has made.
Solution: prepayment
 User may spend more
than he was authorized
to spend.
Solution: penalties/deterrence
Robustness against Fraud
 Any
party (user/merchant/
PSP) may try to cheat
another.
 Any two parties may try to
cheat the third.
Previous Work: Electronic Check
Simplest form of payment scheme.
 User pays a merchant for transaction by
digitally singing on piece of data which
identifies transaction.
 Merchant deposits by sending a Check to
the Bank.
 Bank credits a merchant and charges the
user (after checking the sign).
 So What is the problem?

Problem:
 No
aggregation: every check spent is
returned to the PSP.
 PSP must be on-line all the time.
Previous Work: PayWord
 Rivest
and Shamir ’96
 Emphasis on reducing public-key
operations by using hash-chains
instead:
x0 x1 x2 x 3 … xn
 User signs x0 and releases next xi
for next payment.
 Merchant can check every xi, i>0. How?
Example:
Assume after 70 transactions, merchant
has x70
 He checks hash(x70)= x69
 Merchant sends x70, x0 to the bank (if he
want to).
 Bank checks if [hash70(x70)]= x0.
 If true, bank credits merchant by 70¢,
charges the user by 70¢ (assume fees
inside).

Problem:
 Session-level
aggregation only.
– Each User has established his own Hchin with the merchant.
 So…
– if a user spend only 1¢, to deposit 1¢,
the merchant or the bank would lose
money!
Another Previous Work
 Rivest
and Shamir ’96 - MicroMint
– No aggregation: each coin is returned to
PSP.
 Manasse
et al. ’95 – Millicent
– User buys merchant-specific scrip from
PSP for each session.
– Requires PSP to be on-line for scrip
purchase
– Session-level aggregation only
Previous Work: Lottery Tickets
 “Electronic
Lottery Tickets as
Micropayments” – Rivest ’97
Payments are probabilistic
 First schemes to provide
global aggregation:
payments aggregated across
all user/merchant pairs.
Lottery Tickets
 scheme:
– Assume given S - selection rate between
0 to 1.
– For each micropayment - interact
according to a pre-determined protocol.
– If micropayment selected, user pays 1/s
times bigger than originally amount.
Protocol example:





Merchant gives user hash value Yi=hash(yi+1)
User writes Merchant check: “This check is worth
$10 if three low-order digits of
h-1(Yi) are 756.” (Signed by user, with certificate
from PSP.)
Merchant “wins” $10 with probability 1/1000.
Expected value of
payment is 1¢.
Bank sees only 1 out of
every 1000 payments.
Merchant can, not provide the
merchandise but …
it’s only cent
Problems:
 Interaction:
the user and the merchant
must interact to select micropayments.
 User risk: the scheme burdens the user
with the risk that he may have to pay more
than he should.
 Y can be given by statistical approach (if
merchant has enough “place” to store all
“good y’s …")
Goals for new works:
 Non-interactive
 Fair
to user: user never
“overcharged”
MR1
 Like
Lottery Tickets payments will be
selected according to S.
 No interaction between user to
merchant.
 Idea:
– User sends Check – C, C will be payable
if it worth some value.
– Merchant can easily compute this value
Basic scheme
Each U,M establish public key
 Let T denote transaction
 T contains: User, Merchant, Bank,
merchandise, time, T value, …
 Assume T value is const.
 F(.) – public function, input string, output
number between 0 to 1.
 Example:

– F(110)=0.110
Payments
A
user-U pays a merchant-M for T by
sending M the check-C=SIGu(T)
 C is payable if F(SIGm(C))<S
 If C is payable M send to bank-B, C,
SIGm(C)
 If M’s, U’s signature are correct, B
credits M’s count with 1/S and debits
U’s account with 1/S.
Properties
 Payment
phase is non-interactive
 F(SIGm(C)) is unpredictable to U. next
 B can checks if SIGm(C) is sign on C.
 No cheating. Later
 Note: All
signature are deterministic
U can’t guess F(.)
 We
use RSA signature.
 L= length of SIG
 c*Log(L) last bits of signature are
indistinguishable
 If L=1024 ,c=2 User can’t knew last
20 bits. (c is const grater than 1)
 F(.) return 20 last bits of signature.
 S could be till 1/220
No cheating
B
and U can’t cheat M
– SIGm(C) is unpredictable to both of them.
– Even if U, B saves history

M and U can’t cheat B
– SIGm(C) is deterministic.
– Public key is chosen before transaction.
– SIGu(T) unpredictable to M,B
M
and U can’t cheat B
Practical variant
S
could be a number, so C payable if
F(SIGm(C))<S, OR the property that last X
bits of C equal to F(SIGm(C))
 Using SIGm(Vi) for every day or time
interval, minimizes M’s signatures.
– Vi can be computed by hash(Vi+1)
– M should delivers the Checks to the Bank after
day/time interval, WHY?
– Protecting against malicious user/bank.
MR1 conclusions:
Non-interactive scheme
 No fair to user Possibility of user’s
excessive payments.
 Very small Possibility that the user
will be debited more than
micropayments
 Possibility decreases with number of
micropayments increase

MR2
Goal:
– fair to user
What’s new?
 The
risk of MR1 scheme, shifted
from User to the Bank.
 Advantage of this scheme is
simplicity
– Doesn’t prevent cheating
– Punishes “cheating parties”
Basic scheme
 Each
U,M establish public key
 All signature are deterministic
 A user-U pays a merchant-M for T by
sending M the check-C=SIGu(T)
 User include time, serial number – SN in
every Check.
 C is payable if F(SIGm(C))<S
 If C is payable M send to B, C, SIGm(C)
Selective deposit:
 Let
maxSN denote the maximum
serial number of a payable C of U
processed by B so far.
 If the new C is payable, B credits M’s
count 1/S ¢, debits U’s count by SNmaxSN, maxSNSN.
User charged three cents
Achievements
 Non-interactive
 Fair
to user: user never “overcharged” –
easy to prove!
 But what about cheating?
Cheaters catching
 There
is possibility to catch cheaters
by two ways:
– If a new SN of transaction is equal to
SN before.
– If SN and the time of transaction
doesn’t suitable
What about collusions ?
 Like
MR1, M & B can’t cheat U.
 Like MR1, U & B can’t cheat M.
 But malicious M ,U can cheat B!!!
 How?
– Cause check will be payable all the time,
thus B credits M by 1/S, debits U by
SN-SNmax.
Example:
 Let
S=1/1000, that means for each
micropayments there is possibility of
1/1000 to be chosen.
 If micropayments equal to 1¢ M has
to be paid 10$ for each winning.
 if for every micropayments M wins, B
should pays M 10$, debits U 1¢
 Bank lose 9.99$ each transaction.
solution
 Bank
may keeps statistics and throw out of
the system U/M whose payable checks
cause exceptions.
 Small probability that honest U/M looks
like malicious.
 Those honest U/M can be convinced that
they caused losses to the bank, and may
accept being under MR1 scheme.
Conclusions
 Merchant
is still paid 1/S for each winning
payment, while user is charged by
difference between sequence numbers
seen by Bank.
 Users severely penalized for using
duplicate sequence numbers.
 If user’s payments win too often, he is
converted to basic probabilistic scheme.
 Bank can manage risk.
MR3
 On
this scheme, Bank determines
which checks are payable.
 A user-U pays a merchant-M for T by
sending M the check-C=SIGu(T)
 U includes every T a SN
Selective deposit:
 Let
t’, t denote the time M’s last,
current deposit.
 M group all C into n list,L1….Ln .
 Vi=sum checks on Li, V=sum of Vi
 Ci=commit (Li, Vi)
 M sends to B: SIGm( t, n, V, C1, … ,Cn )
 B verifies last deposit time.
Selective deposit - continue
B selects k, and sends i1,…,ik to M.
 M responses by de-committing Ci1…Cik
 B credits M’s count with V¢
 B debits users whose checks belong to
Li1…Lik according to SN like MR2.
 If B feels something wrong (time, SN, sum,
Li, Vi ), he throw M/U.
 B also can throw M/U if they have any
exceptions of statistical data, like MR2.

Properties
k is arbitrary and up to the bank.
 If there is more attempted fraud, a larger
value of k may be used.
 Recommended K>1 try to catch fakes
checks.
 M can chose t
 Like MR2,M & U can cheat B, but B can
identify them, and throw them out of
system  to risky.

Conclusions
 those
micropayments schemes
– Is highly scalable: bank can support
billions of payments by processing only
millions of transactions (1000x
reduction)
– Provides global aggregation
– Supports off-line payments
– Provides for non-interactive payments
– Protects user from statistical variations
(The End)