1. Micropayments Revisited Background for Peppercoin scheme By Willer Travassos

2. Outline 1.Introduction to Electronic Payments 2.Motivation 3.Scheme proposal 4.The MR1 algorithm 5.The MR2 algorithm 6.The MR3 algorithm

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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))

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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)