Post on 13-Jan-2016
Micropayments RevisitedBackground for Peppercoin scheme
By Willer Travassos
Outline
1. Introduction to Electronic Payments2. Motivation3. Scheme proposal4. The MR1 algorithm5. The MR2 algorithm6. The MR3 algorithm
Basics of e-Payments Payment schemes
always consist of 3 basic parties: The User/Buyer The Merchant/Seller The Bank
These parties are not necessarily singular
They can be more than 3 individuals, or computer programs, or devices
Electronic Checks: an existing e-Payment method It is the simplest form of making payments Roughly speaking, they are like normal
checks, but digitally signed Therefore they contain info about a user-
merchant transaction (e.g., amount, user name, merchant name, and etc)
Banks are responsible for examining the check’s validity, before charging the user and crediting the merchant
The validity of checks may be supported, by using digital certificates
Micropayments Even though micropayments(MP) can be
done using e-checks, its processing costs may be superior to the MP’s value
Therefore repeated payments make a user unnecessarily pay a value many times bigger than his actual MP
Fortunately, these repeated processing costs can be avoided by aggregating several MPs into larger ones
Making the processing costs relatively small to the aggregated MPs
Micropayments
Here are some Micropayment models that have been researched: Millicent, by Mark S. Manasse PayTree, by Charanjit Jutla, and Moti
Young PayWord, by Ronald L. Rivest and Adi
Shamir Micromint, by Ronald L. Rivest and Adi
Shamir
Motivations
To improve on existing schemes by: Creating a more efficient micropayment
method Reducing the number of processing costs
charged by a bank Making it more user friendly/simpler for
merchants and users
Proposed Solution
By using probabilistic distribution, the author claims that: Information exchanging protocols
become more independent Automation of the protocols allows
exclusion of human parties in the payment set up and evaluation
Simpler user interfaces can be created
Basis for the Peppercoin scheme:Payword The Payword method consists of a one-way
hash function that computes a chain of values (xi = H(xi+1), for I = 0 ,…, n )
The root, x0, of this function is digitally signed by the user and sent to a merchant
After that, each user payment is made by releasing the next xi.
The merchant verifies its validity, by checking if hashing xi, gives the previous element in the chain
When the merchant is done he charges the user by i cents
Basis for the Peppercoin scheme:Rivest Lottery
For each MP a known probability s, between 0 and 1, is defined
The user and the merchant interact in order to select a protocol that chooses MPs to paid with probability s
This scheme also uses chain values produced by a hash function, but each, the user and the merchant, has one
Basis for the Peppercoin scheme:Rivest Lottery The merchant gives the root w0 to the user
(wi = H(wi+1), for i = 0,…,n) Afterwards the user calculates its chain-
values with root x0, and includes w0 in his digital signature
Then with a selection rate of s, a MP will be accepted only if xi mod 1/s I equals to wi mod 1/s.
This selected MP is then deposited as a macropayment for the value of 1/s cents
At the end, the merchant can see whether a micropayment has been accepted or not
Problems with both approaches
Problem with Payword: Since each user has its own, unique
chain of values, the merchant cannot aggregate MPs of different users
Problems with Rivest’ Lottery: There is a risk, which the user may pay
more than he should The user-merchant interaction for MP
selection slows down the transaction
MR1 Improves on the previous protocols
by: letting the merchant know right away
whether a MP has been selected for payment or not
Totally excluding the user-merchant interaction to decide on a selection rate s.
This is achieved by utilizing public keys in the payment protocol
MR1 In Rivest’s Lottery checks are selected to
be deposited by the selection protocol (the user-merchant interaction)
MR1, contrarily to Rivest’s Lottery, checks are “marked” as payable or not
Markings of checks are done when the user creates a check. They are done automatically and without the user interference
This is done so that the number of checks marked payable is approximately s
MR1: How it works The user and the merchant establish
their own public keys to be used in a deterministic digital signature
A function F is used to determine the “payability” of the check
The user “pays” the merchant for a transaction, by sending a digitally signed check (i.e., check = SIG(transaction))
MR1: How it works
The check is payable if function F(Merch-SIG(check)) < s
The bank then receives from the merchant check and Merch-SIG(check)
Then it determines, using the received info, whether this check can be deposited or not
MR2 Improves from MR1 by working
around the overcharging (by bad luck) problem
The risk of overcharging switches from the user to the bank
This is done since bank can handle such problems, while protecting users from possible (although unlikely) extra charges
MR2: How it works The algorithm executes similarly to MR1,
the difference being: When creating a check, the user also includes
time of creation, and a sequential serial number(SN)
When the bank receives info from the merchant it not only checks if the digital signatures are correct, but also: If the check’s serial number is in correct order And, if the time of the attempt deposit is valid
MR2: How it works The bank stores a maximal serial number
(maxSN) for each user. The maxSN is the SN of the last accepted check
When the bank receives a check, it credits the merchant with 1/s cents, and charges the user with SN – maxSN cents
If any received information, by the bank, is incorrect or invalid, the payment will not go through and users may be excluded from the bank system
MR3 It is the same as MR2, but it tackles
implementation and the MR1 problem in a different manner
It gives the bank greater control and flexibility over money operations
Now it is the bank who determines which checks are payable or not
It takes away the ability of a merchant to see if a check is payable or not
MR3: How it works The user and the merchant, once again,
determine their public keys for digital signing
Digitally signed checks, with serial numbers, are sent from the user to the merchant
The merchant groups all checks received between time a and b (usually the last and current deposit time) into n lists, with a total Value of V cents
MR3: How it works The merchant then sends all lists and their
total values, as a one way hash function, to the bank
The bank verifies that the deposit time is correct, and chooses k indices for the list of checks
These indices are then checked by the merchant, and an answer is sent back to the bank to confirm transaction
The bank then charges the users that are referenced by the k indices and credits the merchant with V cents
References S. Micali and R. L. Rivest. Micropayments revisited. In
B. Preneel, editor, Proc. Cryptography Track at RSA Conference 2002, pages 149–263. Springer, 2002. Lecture Notes in Computer Science No. 2271.
Ronald L. Rivest. Peppercoin Micropayments Ronald L. Rivest and Adi Shamir. PayWord and
MicroMint–two simple micropayment schemes. In Mark Lomas, editor, Proceedings of 1996 International Workshop on Security Protocols, volume 1189 of Lecture Notes in Computer Science, pages 69–87. Springer, 1997. (Also available in Crypto-Bytes, volume 2, number 1 (RSA Laboratories, Spring 1996), 7–11
Peppercoin web site. (http://www.peppercoin.com)