Combating Double-Spending Using

Cooperative P2P Systems

Author : Ivan Osipkov , Eugene Y. Vasserman , Nicholas Hopper , Yongdae Kim

Source : International Conference on Distributed Computing Systems, 25-27 June 2007,page 41-50 Presenter : Hsiao-Chi Chiang (江小琪 )

Date : 2010/10/15

1

Outline

Introduction E-cash system Algorithm Security Complexity Experiment result Conclusions

2

Introduction Goal

Introduces a new peer-to-peer system architecture to prevent double-spending without requiring an on-line trusted party or tamper-resistant software or hardware.

Scenario This system design is a three-party model, with

the broker as a dedicated (but not necessarily on-line) server

the merchant as a drop-in module for an existing web server

the client as a browser plug-in

3

E-cash system

4

Client C

Broker B

Witness 2

Merchant 2M

Witness 1Mc

Merchant 1

BankE-cash unaware

(3)Certify e-coin C

(1)Withdraw e-coin(s) C (4)Sign payment transcript

(2)Buy with e-coin C

(5)Redeem payment transcript(s)

Cash transactions

Protocol Operations with e-cash involve three protocols:

withdrawal payment Deposit

(1) Let q be two large primes (2) g be a random generator of order q(3) ˂g˃ is subgroup generated by g

(4) let g 1 and g 2 be two random generators of ˂g˃(5) B chooses a secret key x and publishes the

authenticated key y = g x 5

Algorithm 1- Withdrawal Protocol

6

Broker B Client C

(1) Send a, ba=gu , b=gs Zd

random u,s,d Z= (info) Ƒ (2) Send e

1.Choose: random ti , i=1,…,4 and x1,x2,y1,y2 2.Compute:• α=agt1yt2 , β=bgt3 z t4

• ϵ = Η(α||β||z|| A ||B)• A = g1

x 1g2x 2, B = g1

y 1g2y 2

• e = ϵ-t2-t4 mod q

(3) Send ( r , c , s )c = e-d mod q r = u-cx mod qx= secret key

(4)Client Compute ρ = r+t1 mod q ω= c+ t2 mod q σ = s+t3 mod q δ = e-c+t4 mod q

Check equality ω+δ = ϵ= Η(gρyω||gσzδ|| z || A ||B) mod q The bare coin = ( ρ , ω , σ , δ , A ,B ) Attaches the SigB(version/date , {IMc , r Mc,1 , rMc,2}) C = ( ρ , ω , σ , δ , A ,B , SigB(version/date , {IMc , r Mc,1 , rMc,2}))

(1)(2)

(3)

(0)Publish SigB(version/date , {IMc , r Mc,1 , rMc,2})

Algorithm 2- Payment Protocol

7

Client CWitness

McMerchant

M

(1) (coin_hash , nonce)

(2) SigMc(coin_hash , nonce , h(ν) , te , commit )

(3) Payment transcript = ( C , r1, r2 , IM , data/time) SigMc (coin_hash , nonce , h(ν) , te , commit ) salt c

(4) Payment transcript = ( C , r1, r2 , IM , data/time , salt c)(5) SigMc ( payment transcript ) or (x1,x2) and/or (y1,y2) or refuse

(6) Service , (x1,x2) and/or (y1,y2)

Coin_hash= h ( ρ , ω , σ , δ , info, A ,B )nonce =h(salt c ||IM ) , salt c is randomIM is the identify of the merchant

r1=x1+d y‧ 1

r2=x2+d y‧ 2

d=Ho(C,IM,data/time)M check witness, commitment, nonce and A B‧ d=g1

r1 g‧ 2r2

v is either some random value, or tuple (x 1 , x 2 ) or (y 1 , y 2 )

Mc check payment transcriptcheck nonce =h(salt c ||IM )

(1)

(3)

(2)

(4)

Algorithm 3- Deposit Protocol

8

Merchant M

Broker B

(1)Send payment transcript , SignMc (payment transcript )

(2) B searches its database to determine if the bare coin = ( , , , , info, A, B) has ρ ω σ δ previously been deposited.

Payment transcript = ( C , r1, r2 , IM , data/time , salt c)C = ( ρ , ω , σ , δ , A ,B , SigB(version/date , {IMc , r Mc,1 , rMc,2}))B verifies its own signature on the coinB verifies the signature of the witness on the payment, computes d and checks the A B‧ d=g1

r1 g‧ 2r2

Security If the client knows a representation of A (B) :

1) the client actually constructed the coin. 2) the client knows no other representation of A (B).

we can make the following conclusions: 1) only the coin owner can successfully make a

payment. 2) a payment transcript does not allow one to

generate another payment transcript. 3) if the coin owner double-spends, the

representation of A and/or B can be extracted which serves as a definitive proof of double-spending.

9

Complexity

Exp Hash Sig Ver

Withdrawal ClientBroker

123

41

00

10

Payment ClientWitnessMerchant

077

366

020

113

Deposit MerchantBroker

06

04

00

01

10

Table.1 Number of cryptograghic operations

+2 -1

Experimental Result

Client total time Client bytes transmitted

Average 1789 ms 1.6 KB

St. dev. 324 ms 1.3 B

11

Table 2. Wall-clock runtime and bandwidth for payment protocol over 100 trials

The client and broker were located in Wisconsin, the witness in California, and the merchant in Massachusetts.

An informal survey of a popular ad-supported web site shows that it serves up 37.13KB in two ad images and associated links for the main page.

Conclusions

A framework for anonymous e-cash that prevents double-spending without an online trusted authority or special-purpose hardware.

If the coins are stolen, the damage to the client will consist only of the value of the stolen coins.

12