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)