A New Micro-payment Protocol Based on P2P Networks
Zou Jia Si Tiange Huang Liansheng
Department of Computer Science and Technology
Tsinghua University, Beijing, P.R.China, 100084
zouj03@mails.tsing stg@theory.cs.tsing
hua.edu.cn hua.edu.cn,
Abstract
Introducing micro-payment mechanism into P2P
systems will bring economic incentives to various P2P
applications and encourage peers to share their
resources. In this paper, we present a new micro-
payment protocol, CPay, which exploits unique
characteristics of P2P systems. The protocol
establishes dynamic consistent hashing map between
the set of all peers in the system and its subset of high
performance peers. In each transaction, the payer’s
corresponding high performance peer checks the
transaction to make sure that any illegal use of the e-
coin will be timely detected. The protocol effectively
exploits the heterogeneity of the P2P system and can
achieve load balance.GG
1. Introduction
Micro-payment often refers to the payments too
small in amount to warrant the overhead of current
financial clearing networks. Peer-to-Peer networks
provide a rich research area for micro-payment
protocols. Recent researches revealed that in P2P
applications, selfish peers that refuse to share their
resources (e.g. freeloaders in P2P file sharing systems)
will degrade the system performance.[1] However, if
peers can be paid a small amount of money when they
provide their resources or services (e.g. forwarding
queries for other peers), they will be motivated to
cooperate. Such a mechanism requires an appropriate
micro-payment scheme. Besides, introducing micro-
payment schemes into P2P systems will also bring in
economic incentives, thus make the P2P network a
commerce platform where people can exchange
information and services for money.
It is regret that many of the current micro-payment
mechanisms are not very suitable for the P2P cases.
Millicent [2] and Micro-iKP [3] need an on-line broker to
check all transactions, which deprives the system of
scalability. And scalability is one of the most attractive
properties of P2P systems. In PayWord and similar
Proceedings of the 2005 IEEE International Conference on e-Business Engineering (ICEBE’05)
0-7695-2430-3/05 $20.00 © 2005 IEEE
Dai Yiqi
hls@mail.tsinghua.e dyq@theory.cs.tsing
du.cn hua.edu.cn
mechanisms [4-6] which use a hash chain to represent a
chain of coins, the broker is only responsible for the
distribution and redemption of hash chains. But a hash
chain can only be spent by a certain customer to a
certain merchant. However, in the P2P networks, there
are no such stable customer-merchant relationships as
in B2C commerce. It is probably that a peer will
download 1000 files from 1000 different peers. If
PayWord is used in such a case, the broker still needs
to participate in all transactions. In the probabilistic
schemes proposed in [7], the customer will directly pay
merchant a check, which is payable at a probability of
s, and the merchant can immediately determine
whether the check is payable, and only the payable
checks should be redeemed by the broker, thus the
broker’s workload is further reduced by a factor of s.
But, as for large scale P2P applications, which have
huge number of participants and very high transaction
frequencies, even this scheme will incur too much
overhead on the broker. That’s partly because the coin
is inherently untransferable. That is, once having been
spent, the coin should be redeemed by the broker rather
than can be spent to another party as we usually do in
the real life.
PPay [8] is a pioneering work in the research area of
micro-payments for P2P systems. It uses transferable
coins. Its main idea is to shed the broker’s workload
onto the peers. If a peer, say ‘A’, buys a coin from the
broker, A will become the owner of the coin. As the
coin is transferable, A can spend the coin to B, and B
can spend the coin to C. However, each time the coin
is spent, the coin’s owner A should check the
transaction and make sure that the coin is not double-
spent. If A is off-line when B wants to spend the coin
to C, there are two solutions: First, B can choose
another coin to spend or B can buy a new coin from the
broker; Second, B can ask the broker to take the place
of A. In the latter case, the broker needs to inform A of
this transaction when A becomes on-line again. But
PPay also has its limitations. It does not take the
heterogeneity of the peers into consideration and
overlooks the simple fact that peers having low
bandwidth or peers having little on-line time or peers
 being selfish and lazy are not appropriate to assume the
role of “owner”. Imagine that if many owners are off-
line, the broker will become very busy checking
transactions in place of those owners. Another flaw of
PPay is that the owner has too much authorization and
can easily cheat other peers or collude with other peers.
Other micro-payment schemes for P2P systems include
KARMA [9] and off-line KARMA [10]. Both of them
require a lot of peers to form a bank to check one
transaction, and only if most of the bank members
approve this transaction, the transaction can be made.
Although such schemes are more democratic and
reliable, it is infeasible to implement them because of
the huge bandwidth they will consume.
In this paper, the authors have proposed a new
micro-payment scheme for the P2P network, CPay.
CPay also uses transferable coins. But differing with
previous works, it exploits the heterogeneity of peers.
For each transaction, the payer can compute a hash
function to find an eligible peer to check the coin and
decide whether to authorize the transaction. The broker
is only responsible for selling coins and paying these
eligible peers and needs not to participate in any
transaction. We show that our scheme is load-balance
and secure against various attacks. We also proposed
two variations of CPay: Anonymous CPay which
offers anonymity to the payee and Group CPay which
can reduce the number of the eligible peers required by
increasing their work load, thus to reduce the
managing cost of the broker.
The paper is organized as following. In Section 2,
CPay is introduced and a formal description is given.
In Section 3, the security of CPay is analyzed in detail.
In Section 4, we give a short analysis of the
performance of CPay. Two variations of CPay are
proposed in Section 5. Finally, we conclude our work
in Section 6.
2. CPay
2.1. Goals and Design Decisions
CPay is in nature a debit-based payment protocol.
Peers can acquire coins either by buying them from the
broker or selling services or information to other peers
who have coins. Our Design is aiming at the following
goals.
1. Central broker is only responsible for
distributing and redeeming coins and needs not to take
part in any transactions.
2. The protocol should reduce the distributing and
redeeming workload of the broker as much as possible.
3. Any malicious use of the coins can be prevented
or detected timely.
Proceedings of the 2005 IEEE International Conference on e-Business Engineering (ICEBE’05)
0-7695-2430-3/05 $20.00 © 2005 IEEE
4. The protocol should be independent with the
underlying file searching strategies. CPay should be
able to run over Gnutella, DHT, GIA or future file
locating protocols.
5. The protocol should preserve the scalability of
the original P2P network and make full use of the free
cycles and free bandwidths of the peers in the system.
To fulfill these goals, we make the following
design decisions.
1. Use transferable coins;
A transferable coin can be used many times before
being cashed, thus can reduce the distribution and
redemption workload of the broker.
2. Let the eligible peers do the checking work;
Thus the broker can be relieved from all transactions
while those eligible peers’ free resources can be
exploited. And it will incur no more overhead on the
peers which are not eligible.
3. Use dynamic consistent hashing to map a peer to
an eligible peer which we call BA (Broker Assistant);
Dynamic consistent hashing refers to a family of
hash functions fY: X ˧ Y, where the set of Y can
change dynamically. fY satisfies the following two
conditions:
Condition 1: There exists a very small value ε , for
X
∀y ∈ Y , {x | f Y (x) = y } ≤ ε × ;
Y
Condition 2: By adding an element to or deleting
an element from the set of Y, we can get a new set of
Y’, and for any Y and Y’,
⎛X⎞
{x |f Y (x ) ≠ f Y' (x )} < O ⎜⎜ ⎟⎟ .
⎝Y⎠
Condition 1 means that the elements in X are
almost evenly mapped to the elements in Y. Condition
2 means that when adding an element to or deleting an
element from Y, only a small number of elements in X
need to change their mappings. So, consistent hashing
can be applied to various systems to achieve load-
balance, such as in the design of distributed caching
schemes [11] and P2P file searching strategies [12]. We
introduce this idea into our design of P2P micro-
payment protocols for the same purpose.
2.2. The Formal Description of CPay
2.2.1. Participating Parties. In CPay, the broker is
responsible for the distribution and redemption of the
coins and the management of the eligible peers and
needs not to participate in transactions. So, there are
only three parties involved in a transaction.
a) Payer, the peer that wants to pay in return for
the goods (e.g. services, files).
 b) Payee, the peer that wants to offer goods (e.g. this case, it will receive nothing until it connects to the
services, files) in return for money. system again.
c) BA, the eligible peer which the payer maps to The joining procedure of ordinary peers
and is responsible for the checking of the coin and the When an ordinary peer U joins the system, if it
authorization of the transaction. BA can also be the buys coins from the broker, it will get a partial list of
payer or payee, and those transactions should be the current BA peers from the broker, or it can learn
handled by BA’s mapping BA. The consistent hash the BA information from other peers. The partial list
function must guarantee that no one will be mapped to
will contain ⎡m ⎤ BA peers, where m
itself. ⎢ h × (2k + 1)⎥
2.2.2. Initialization. In CPay, broker controls BA denotes the length of the complete list and h is a
peers by updating or revoking their certificates. At the parameter which can be customized. If we use SetU to
beginning, the broker will select eligible peers to be denote the set formed by those BA peers, SetU satisfies
BA, and updating their certificates, and maintain a list the following 2 conditions:
of current BA peers. And the peers in the system will 1) ∀X , Y ∈ SetU , Set BAx ∩ Set BAy = φ ;
buy coins from the broker by credit-card, debit-card,
check or cash. What we should note here is that broker 2) Let SetU
'
= SetU ∪ SetY , then we can
Y ∈SetU
can add or delete a BA at any time and the peers can
buy coins from the broker at any time. But the system have for ∀Y ∈ SetU' ∀Z ∈( Set BA − SetU' ) ,
can start to run only when there is more than one BA
and more than one coin in the system. SHA1(Y ) − SHA1( X ) ≤ SHA1( Z ) − SHA1( X ) .
Other notations we will use are listed in table 1.
2.2.3. Notations. As we mentioned above, CPay is
designed to allow BA peers to join and leave the Table 1. Notations
network dynamically: Notations Description
The joining procedure of BA peers
If X is selected by the broker to be BA, X will It represents the consistent
receive a signed BA certificate and a partial BA list hashing function we use in
from the broker. The BA peers on the partial list form a CPay, U can be referred to any
subset, say SetBAx, which is a subset of the set of all on- peer in the system, including the
hash(U)
line BA peers, say SetBA. SetBAx satisfies the following BA peer, so does V, W, X, Y, Z.
conditions: The implementation of this
1) |SetBAx| = 2k, where k is a predetermined value; function will be described in the
next part of this section.
2) ∀ Y ∈ Set BAx , ∀Z ∈( Set BA − Set BAx ) ,
It represents a message msg
(msg)S_who
SHA1(Y ) − SHA1( X ) ≤ SHA1( Z ) − SHA1( X ) , signed by ‘who’.
It represents peer U’s mapping
where SHA1(U) returns the hash value of the ID of U BAU
BA, satisfying BAU = hash(U).
by running the well known SHA1 algorithm.
Then X will send all 2k peers in SetBAx messages to It represents the coin, which is
request them to add X to their lists. And all peers in in the form of (BAU’, U,
SetBAx will update their list after they check X’s SNO)S_Broker, where SNO is the
certificate. C global unique identifier of the
The leaving procedure of BA peers coin C and BAU’ is the mapping
If X doesn’t want to be a BA peer any more. It has BA of U when the broker
two choices: 1. Notify the broker by sending all generates this coin.
transaction records it has stored to the broker. In this TS It represents the timestamp.
case, the broker will pay it some money as a reward for It represents the authorization
its work; send the records to the next BA peer Y, message, which is in the form of
which satisfies the following condition: (BAU’, U, TS, C, BAX ക S_BAx.
∀Z ∈Set BA , Au This message will be sent to
payee U by payer X’s mapping
SHA1( Z ) − SHA1( X ) ≤ SHA1(Y ) − SHA1( X ) ; BA BAX. This message
and then notify all peers in SetBAx to delete X from indicates three facts: 1. BAX
their lists. 2. Simply disconnect from the system. In authorized payer X to pay the

Proceedings of the 2005 IEEE International Conference on e-Business Engineering (ICEBE’05)

0-7695-2430-3/05 $20.00 © 2005 IEEE
 coin C to the payee U; 2. TS
indicates the time when this
authorization happened; 3. At
the time of authorization, payee
U’s mapping BA is BAU’.
It represents the requesting
message, which is in the form of
(X, U, Au)S_X. This message is
sent to payer X’s mapping BA,
Re which is indicated in Au, by X.
This message indicates that
payer X requests BAX to
authorize X to pay the coin C
indicated in Au to payee U.
It represents the looking up
message, which is in the form of
Lo (U)S_X. This message is sent by
X to look up the mapping BA of
U.
It represents the hit message,
which is in the form of (U)S_X.
Hit This message is sent by X to tell
the receiver that the mapping
BA is U.
AĺB: msg
It represents that the peer A
sends a message msg to peer B
This operation is executed by
the receiver of Au, the payee,
and includes: 1. Check the
payer’s signature on Au. 2.
check(Au) Check the broker’s signature on
C. 3. Check whether the payee
itself is indicated in Au. This
operation will return 0, if Au is
correct, otherwise return -1.
This operation is executed by
the receiver of Re, the BA
responsible for this transaction,
and includes: 1. Check the
payer’s signature on Re. 2.
Check the BA’s signature on
Au, which is contained in Re. 3.
Check whether the payer is
indicated in Au. 4. Check
check(Re) whether the BA itself should be
responsible for this
authorization by seeing whether
it is indicated in Au; if not,
continue to check whether it is
the payer’s current mapping BA
and the original mapping BA
indicated in Au is off-line; if not
yet, the Re is not correct. 5.
Checking whether TS is the
Proceedings of the 2005 IEEE International Conference on e-Business Engineering (ICEBE’05)
0-7695-2430-3/05 $20.00 © 2005 IEEE
latest in the transaction records
of the coin C in its local
database.
If Re is correct, this operation
will return 0, otherwise it will
return -1.
This operation is executed by
the receiver of Re, the BA
responsible for this transaction,
generate_Au(Re)
and returns a new Au, which
authorizes the payee to own the
coin C.
In this operation, the operator
record (msg) will store msg in its local
database.
This operation sends ‘who’ a
ping(who) ping message, if ‘who’ is on-
line, return 0, else return -1.
2.2.4. The implementation of consistent hashing.
The form of the consistent hash function we use in
CPay is similar with Chord[12], but our implementation
is more simple.
Definition of consistent hashing used in CPay:
hash(U)=BAU, if and only if for ∀X ∈ Set BA and
X ≠ BAU , there is
SHA1( X ) − SHA1(U ) > SHA1( BAU ) − SHA1(U )
.
The looking-up procedure:
If peer U wants to look up the mapping BA of
itself, and let
max {SHA1( X )} =m1, X1 satisfies that
X ∈SetU ' ∧ ping ( X )= 0
SHA1(X1)=m1,
min {SHA1( X )} =m2, X2 satisfies
X ∈SetU ' ∧ ping ( X ) =0
that SHA1(X2)=m2,
min {( SHA1( X ) − SHA1(U )) > 0} =m1
X ∈SetU ' ∧ ping ( X ) =0
’
, X1 satisfies that SHA1(X1’)-SHA1(U)=m1’;
’
U will do as following:
if ( SHA1(U ) > m1) U˧X1: Lo={U}S_U;
else if( SHA1(U ) < m2) U˧X2: Lo={U}S_U;
else U˧X1’: Lo={U}S_U;
While a BA peer Y receives Lo, and let
max {SHA1( X )} =n1, Y1 satisfies that
X ∈SetBAy ∧ ping ( X ) =0
SHA1(Y1)=n1,
min {SHA1( X )} =n2, Y2 satisfies that
X ∈SetBAy ∧ ping ( X ) =0
SHA1(Y2)=n2,
 min {( SHA1( X ) − SHA1(U )) > 0} Step5: Z check (new_Au); if (return 0) ZĺX: ok;
X ∈SetBAy ∧ ping ( X ) =0 else ZĺX: error;
=n1’, Y1’ satisfies that SHA1(Y1’)-SHA1(U)=n1’; Step6: if (BAX==BAX’ || BAX has BAX’s record)
Y will do as following: Stop;
if ( SHA1(U ) > n1) Y˧Y1: Lo={U}S_U; else {BAX ping(BAX’) until return 0;
BAXĺBAX’: new_Au;}
else if( SHA1(U ) < n2) Y˧Y2: Lo={U}S_U;
else Y˧U: Hit={Y1’}S_Y; 3. Security Analysis
2.2.5. Transaction Procedures. Then, we can give a We assume that the broker is reliable. Now we
formal description of the transaction process. To show that CPay can resist most attacks.
simplify the problem, we assume that only one coin be
paid in each transaction. According to how the payer 3.1. Coin Forgery
gets the coin, the transactions fall into two categories.
In CPay, money is transferred in two forms: coin C
a) Payer bought the coin from the broker and authorization message Au. The former includes the
Coin: C= (BAU’, U, SNO)S_Broker signature of the broker whom is reliable according to
Payer: U our assumptions, and the latter includes C. As no one
Payee: X can forge broker’s signature, no one can forge a coin.
Procedure
Step1: U ping(BAU’); 3.2. Coin Thievery
if (return 0) { BAU=BAU’; UĺBAU: Re=
(U, X, C)S_X;} In CPay, all messages are transferred in plaintext
else {BAU=hash(U); UĺBAU: Re= (U, X, for the purpose of efficiency and simplicity, so peers
C)S_X;} may steal a coin C or Au by eavesdropping or by
Step2: BAU check(Re); if (return 0) goto Step 3; processing transactions as BA peers. But because both
else {BAUĺU: error; Stop;} of C and Au specify the BA peer responsible for the
Step3: record (C); BAU generate_Au(Re) return next transaction of the coin, the thief can pay the stolen
new_Au=ഔBAX, X, new_TS, C, BAUകS_BAu; coin to another party only in two cases:
Step4: BAUĺX: new_Au 1) The malicious peer may bribe the BA peer
Step5: X check (new_Au); if (return 0) XĺU: ok; specified in the stolen coin and make the BA collude
else XĺU: error; with it.
Step6: if (BAU==BAU’ || BAX has BAX’s record) 2) The malicious peer may bribe any other peer to
Stop; reassign the coin.
else {BAU ping(BAU’) until return 0; We now show that in both cases the thievery and
BAUĺBAU’: new_Au;} the identity of the colluding BA peer will be disclosed.
Suppose an Au message, Au1= ഔBAZ1, Z1, TS1,
b) Payer acquired the coin from another peer
C, BAX1കS_BAx1, is sent to the broker to be redeemed,
Coin: C= (BAU’, U, SNO)S_Broker
and the broker finds that there is another Au message
Au: (BAX’, X, TS, C, BAY)S_BAy
Payer: X which also includes C, Au2= ഔ BAZ2, Z2, TS2, C,
Payee: Z BAX2 ക S_BAx, having been already redeemed. So, the
Procedure broker will ask BAX1 and BAX2 to hand in the records
Step1: X ping(BAX’); of C. If BAX2 = BAX1, the collusion in case1 is
if (return 0) { BAX=BAX’; XĺBAX: Re= disclosed. If one of them can not hand in the correct
(X, Z, Au)S_X;} Au or C which specifies it to processing the
else {BAX=hash(X); XĺBAX: Re= (X, Z, transaction, the collusion in case2 is disclosed.
Au)S_X;} Otherwise, if the Au1’= (BAX1, X1, TS1’, C, BAY1)
Step2: BAX check(Re); if (return 0) goto Step 3; S_BAy1, is sent by BAX1, Au2’= (BAX2, X2, TS2’, C,
else {BAXĺX: error; Stop;} BAY2) S_BAy2 is sent by BAX2, the broker will ask BAY1
Step3: record (Au);BAX generate_Au(Re) return and BAY2 to hand in their records about C. Repeating
new_Au=ഔBAZ, Z, new_TS, C, BAXകS_BAx; the process, the misbehaving BA will be detected at
Step4: BAXĺZ: new_Au last.
However, if in the transaction history of the coin C,
more than one BA have been bribed, the BA who

Proceedings of the 2005 IEEE International Conference on e-Business Engineering (ICEBE’05)

0-7695-2430-3/05 $20.00 © 2005 IEEE
 misbehaved earlier will be disclosed only when the all
the BAs, who misbehaved later than it, hand in the
original stolen Au messages before they misuse them.
So, we prescribe that if k copies of the same C
transferred to the broker for cashing, and uG malicious
BAs have been disclosed, where u ˺ ’, the u BAs
should be punished to share the total loss of the broker,
including k-1 stolen coins and the expenditure of
inquisitions. So, it is more beneficial for the
misbehaving BA to store and hand in the original
stolen Au.
3.3. Other Attacks
3.3.1. Coin Double-Spending. The case of double-
spending is similar to coin thievery, in that double-
spending refers to a peer spend a coin twice or more,
which equals to the situation that the peer stole the coin
from itself. So we omit the proof here.
3.3.2. BA or Broker Masquerading. No one can
masquerade as BA or broker, because everyone in the
system can obtain the identity certificate of the broker
and the BA peers.
3.3.3. Attacking BA. The malicious peer Z, who wants
to double-spend Au=ഔBAZ, Z, TS, C, BAX ക S_BAx,
may attack the BAZ to be off-line and then send an Re
including Au to the new mapping BA, BAY= hash(Z).
BAY will trust Z and authorize the transaction.
However, according to the protocol, when BAZ
becomes on-line again, BAY will send BAZ the Re
message received from Z, and then BAZ will find out
the double-spending of Z.
4. Performance Analysis
The design of CPay takes the performance issues
into consideration in the following aspects:
1) For the broker: In CPay, the broker is
responsible for the distribution of the coins, the
redemption of the coins, the selection of the BAs, the
revocation of the BAs, and the inquisition of the
crimes, all of which can be done off-line. That is, by
relieving the broker from the on-line work of
transaction checking, the scalability of the P2P system
can be preserved. And because the coin can be
transferred many times before being cashed, the
broker’s coin distribution and coin redemption work is
also greatly reduced.
2) For the BA peers: BA peers are selected from
peers those who have more on-line time, more
bandwidth, more computational power, and more
credibility. So, it is reasonable to hire them to do the
Proceedings of the 2005 IEEE International Conference on e-Business Engineering (ICEBE’05)
0-7695-2430-3/05 $20.00 © 2005 IEEE
checking work. And the consistent hashing can realize
load-balance among BA pees.
3) For the payers: What they need to do is to
generate a Re message, sign it and send it to its
mapping BA. In most cases, they need not to find the
mapping BA by themselves. They need to do that only
when the BA specified in the Au is off-line, which is a
rare case according to the BA-selection principles. And
even in that case, most of the computational work is
completed by the BA peers and the payer only needs to
send its request to certain BA.
4) For the payees: What they need to do is to
check the Au messages sent to them.
5. Two Variations
5.1. Anonymous CPay
In CPay, all transactions started by a peer will be
recorded in the local database of its mapping BA. So,
there is no anonymity in the previous protocol. Now,
we give a variation of CPay, which will offer
anonymity so that the BA peer will not know who the
payee is. Before the description of Anonymous CPay,
we will introduce more notations. By K, we denote the
symmetric key. By PA, we denote the public key of
peer A. By EK(msg), we denote the encryption of msg
under the symmetric key K. By EPA(msg), we denote
the encryption of msg using A’s public key PA.
The transaction Procedure of Anonymous CPay:
Au:ഔBAW, W, TS, C, BAകS_BA
Payer: W
Payee: X
Step1: W hash(X)=BAX; WĺBAW: EPBAw(K),
Re= (ൃ, BAX, Au)S_W;
Step2: BAW check(Re); if (return 0)goto Step 3;
else {BAWĺW: error; Stop}
Step3: BAW record(Re) generate_Au(Re) return
new_Au=ഔBAX, new_TS, C, BAWകS_BAW;
Step4: BAWĺW: EK(new_Au);
Step5: W check (new_Au); if (return 0) {WĺX:
EPX(K’), EK’(new_Au); goto Step 6;} else{WĺBAW:
error; goto Step 1;}
Step 6: X check (new_Au); if (return 0) XĺW: ok;
else {XĺW: error; Stop}
5.2. Group CPay
In CPay, the broker need to manage all BA peers,
update their certificate, pay them when they finish their
work properly, and punish them when they misbehave.
So, if the number of peers in the system increases,
CPay will require the broker to increase the number of
BA peers to maintain the efficiency of the system. So,
 the broker’s work load of managing these BA peers
will increase. To solve this problem, we proposed the
idea of Group CPay, in which k BA peers will be
responsible for one transaction. If there are m BA peers
in the system, then the number of combinations will
⎛m⎞
be ⎜⎜ ⎟⎟ , and the consistent hashing will map each
⎝k⎠
peer to a combination of k BA peers. And by letting k
peers check one transaction, the protocol will increase
the difficulty of collusion, thus increase the robustness
and security of the system.
6. Conclusion
This paper proposed a new kind of P2P micro-
payment protocol, CPay. CPay uses transferable coins,
and sheds the checking work onto the peers which have
more bandwidth, more on-line time, higher
computational power, and more credibility. Thus,
CPay reduces the workload of the broker from
controlling all transactions in the system to controlling
only BA peers. Besides, the consistent hashing that the
CPay protocol exploits can achieve load-balance
among the BA peers, which will effectively improve
the system performance. CPay is also a secure payment
protocol, in which all coin forgery, coin thievery,
double-spending and masquerading will be detected.
The paper also proposed two variations to offer more
trade-off shemes for implementation.
However, our work doesn’t cover the following two
aspects:
1. How will the process of consistent hashing affect
the system performance? What is the relationship
between the bandwidth it will consume and the
dynamics of the system, such as the number of the
peers, the number of the BAs, and the frequency of the
transactions and so on?
2. How should we apply CPay to the current P2P
applications to offer a complete incentive mechanism
for those systems?
Both of the two aspects are very important and will
be the directions of our future research work.
7. References
[1] Zihui Ge, Daniel R. Figueiredo, et.al. Modeling Peer-Peer
File Sharing Systems. Proceedings of INFOCOM 2003,
Santa Fe, NM: IEEE, 2003, pp.2188-2198.
[2] S.Glassman, M.Manasse, et.al. The Millicent Protocol for
Inexpensive Electronic Commerce
http://www.research.digital.com/SRC/millicent/papers/millic
ent-w3c4/millicent.html, 1995.
Proceedings of the 2005 IEEE International Conference on e-Business Engineering (ICEBE’05)
0-7695-2430-3/05 $20.00 © 2005 IEEE
[3] R.Hauser, M. Steiner, and M. Waidner. Micro-payments
based on ikp. Proceedings of 14th Worldwide Congress on
Computer and Communications Security Protection. Paris-La
Defense, France: C.N.I.T, 1996, pp.67-82.
[4] R. Rivest and A. Shamir. Payword and micromint: Two
simple micropayment schemes. Mark Lomas. Proceedings of
1996 International Workshop on Security Protocols. Berlin,
Germany ദ Springer Verlag, Lecture Notes in Computer
Science No. 1189, 1997, pp.69--87.
[5] R. Anderson, C. Manifavas, and C. Sutherland. Netcard -
a practical electronic cash system. Mark Lomas. Proceedings
of 1996 International Workshop on Security Protocols.
Berlin, Germany ദ Springer Verlag, Lecture Notes in
Computer Science No. 1189, 1997, pp.49--57.
[6] T. Pedersen. Electronic payments of small amounts. Mark
Lomas. Proceedings of 1996 International Workshop on
Security Protocols. Berlin, Germany ദ Springer Verlag,
Lecture Notes in Computer Science No. 1189, 1997, pp.59 -
68.
[7] S. Micali and R. L. Rivest. Micropayments revisited.
Lecture Notes in Computer Science 2002, v 2271, pp.149ˀ
263.
[8] B.Yang and H.Garcia-Molina. PPay: micropayments for
peer-to-peer systems. Proceedings of the 10th ACM
Conference on Computer and Communication Security, New
York, USA: ACM Press, 2003, pp.300--310.
[9] V. Vishnumurthy, S. Chandrakumar, E.G.Sirer. KARMA:
a secure economic framework for peer-to-peer resource
sharing. Proceedings of the Workshop on the Economics of
P2P Systems, Berkeley, USA, 2003. Paper published on
website:
http://www.sims.berkeley.edu/research/conferences/p2pecon/
program.html
[10] F. D. Garcia and J.-H. Hoepman. Off-line Karma: A
Decentralized Currency for Static Peer-to-peer and Grid
Networks. Coming in 5th International Network Conference
(INC2005), July 5-7 2005.
[11] D.Karger, E.Lehman, T.Leighton, et al. Consistent
Hashing and Random Trees: Distributed Caching Protocols
for Relieving Hot Spots on the World Wide Web[A].
Proceedings of the 29th Annual ACM Symposium on Theory
of Computing[C]. New York, USA: ACM Press, 1997,
pp.654-663.
[12] I.Stoica, R.Morris, D.Karger, et al. Chord A Scalable
Peer-to-peer Lookup Service for Internet Applications[A].
Proceedings of ACM SIGCOMM[C], New York, USA:
ACM Press, 2001, pp.149-160.
Proceedings of the 2005 IEEE International Conference on e-Business Engineering (ICEBE’05)
0-7695-2430-3/05 $20.00 © 2005 IEEE