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

2. Outline  Introduction  E-cash system  Algorithm  Security  Complexity  Experiment result  Conclusions 2

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

4. E-cash system 4 Client C Broker B Witness 2 Merchant 2 M Witness 1 Mc Merchant 1 Bank E-cash aware E-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

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

6. Algorithm 1- Withdrawal Protocol 6 Broker BClient C (1) Send a, b a=g u, b=g s Z d random u,s,d Z=Ƒ(info) (2) Send e 1.Choose: random t i, i=1,…,4 and x 1,x 2,y 1,y 2 2.Compute: α=ag t1 y t2, β=bg t3 z t4 ϵ = Η(α||β|| z || A ||B) A = g 1 x 1 g 2 x 2, B = g 1 y 1 g 2 y 2 e = ϵ-t2-t4 mod q (3) Send ( r, c, s ) c = e-d mod q r = u-cx mod q x= secret key (4)Client Compute ρ = r+t 1 mod q ω= c+ t 2 mod q σ = s+t 3 mod q δ = e-c+t 4 mod q Check equality ω+δ = ϵ= Η(g ρ y ω ||g σ z δ || z || A ||B) mod q The bare coin = ( ρ, ω, σ, δ, A,B ) Attaches the Sig B (version/date, {I M c, r M c, 1, r M c, 2 }) C = ( ρ, ω, σ, δ, A,B, Sig B (version/date, {I M c, r M c, 1, r M c, 2 })) (1) (2) (3) (0)Publish Sig B (version/date, {I M c, r M c, 1, r M c, 2 })

7. 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, r 1, r 2, I M, data/time) Sig Mc (coin_hash, nonce, h(ν), te, commit ) salt c (4) Payment transcript = ( C, r 1, r 2, I M, data/time, salt c) (5) Sig M c ( payment transcript ) or (x 1,x 2 ) and/or (y 1,y 2 ) or refuse (6) Service, (x 1,x 2 ) and/or (y 1,y 2 ) Coin_hash= h ( ρ, ω, σ, δ, info, A,B ) nonce =h(salt c ||I M ), salt c is random I M is the identify of the merchant r 1 =x 1 +d ‧ y 1 r 2 =x 2 +d ‧ y 2 d=Ho(C,I M,data/time) M check witness, commitment, nonce and A ‧ B d =g 1 r1 ‧ g 2 r2 v is either some random value, or tuple (x 1, x 2 ) or (y 1, y 2 ) Mc check payment transcript check nonce =h(salt c ||I M ) (1) (3) (2) (4)

8. Algorithm 3- Deposit Protocol 8 Merchant MBroker 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, r 1, r 2, I M, data/time, salt c) C = ( ρ, ω, σ, δ, A,B, Sig B (version/date, {I M c, r M c, 1, r M c, 2 })) B verifies its own signature on the coin B verifies the signature of the witness on the payment, computes d and checks the A ‧ B d =g 1 r1 ‧ g 2 r2

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

10. Complexity ExpHashSigVer WithdrawalClient Broker 12 3 4141 0000 1010 PaymentClient Witness Merchant 077077 366366 020020 113113 DepositMerchant Broker 0606 0404 0000 0101 10 Table.1 Number of cryptograghic operations +2

11. Experimental Result Client total timeClient bytes transmitted Average1789 ms1.6 KB St. dev.324 ms1.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.

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