How to Use Bitcoin to Design Fair Protocols - PowerPoint PPT Presentation

how to use bitcoin to design fair protocols n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
How to Use Bitcoin to Design Fair Protocols PowerPoint Presentation
Download Presentation
How to Use Bitcoin to Design Fair Protocols

play fullscreen
1 / 42
How to Use Bitcoin to Design Fair Protocols
130 Views
Download Presentation
zan
Download Presentation

How to Use Bitcoin to Design Fair Protocols

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. How to Use Bitcoin to Design Fair Protocols IddoBentov (Technion) Ranjit Kumaresan (Technion) ePrint 2014/129

  2. Secure Computation • Most general problem in cryptography • Feasibility results [Yao86,GMW87,…] • Moving fast from theory to practice x y f(x,y) f(x,y)

  3. Secure Computation Best Possible Security • Privacy • Correctness • Input independence • Fairness x y ≈ f(x,y) f(x,y) x y f(x,y) f(x,y) Protocol for secure computation emulates a trusted party Ideally…

  4. Fairness in Secure Computation f(x,y) • 2-party fair coin tossing impossible [Cle86] • Fair secure computation possible only in restricted settings • For restricted class of functions [GHKL08,Ash14] • If majority of parties are honest [BGW88,RB89]

  5. Fair Exchange [Rab81,BGMR85,ASW97,ASW98,BN00,….] • E.g., contract signing, digital media • Special case of secure computation • Authenticity & fairness Contract signing: • Two parties want to sign a contract • Neither wants to commit first • The other signer could be malicious…

  6. Fair Exchange [Rab81,BGMR85,ASW97,ASW98,BN00,….] Fair exchange is impossible [Cle86,PG99,BN00]

  7. Workarounds I • Gradual release mechanisms [BG89,GL91,BN00,GJ02,GP03,Pin03,GMPY06,…] • Partial fairness [MNS09,GK10,BOO10,BLOO11] Control adversary’s advantage in learning the output first Requires lots of rounds

  8. Workarounds II • Optimisticmodel [Rab81,BGMR85,ASW97,GJM99,Mic03,DR04,KL10…] • Trusted arbiter restores fairness • Contacted only when required • Requires trusting a third party • Potentially need to pay “subscription fee” to arbiter f(x,y) Bad guys get away with cheating

  9. Workarounds III • Penalty model [ASW00,MS01,CLM07,Lin08,KL10] • Deviating party pays monetary penalty to honest party • Bad guys get away with cheating lose money! “Secure computation with penalties”

  10. Penalty Model • “Legally enforceable fairness” [Lin08] • Requires central trusted bank • “Usable optimistic exchange” [ASW00,MS01,CLM07,KL10] • Requires trusted arbiter (+ e-cash) • Ideally… • Decentralized system; no trusted third party • Widely adopted

  11. Bitcoin[Nak08] • Decentralized digital currency • Essentially implements a bank • Provides some level of anonymity • (Relatively) widely adopted • Lots of recent research activity • “Securely” implements a bank Defn.1: A cryptosystem is secure if my bank uses it and I’m not losing money

  12. Bitcoin[Nak08] • Wide variety of transactions • Expressivevia Bitcoin “scripts” • Wide range of applications • E.g.: Lottery, gambling, auctions,… • Currently done using a “trusted” party • Can we use secure computation to replace the trusted party? • “Fairness” issues

  13. Secure computation with penalties Can Bitcoin replace a trusted bank/arbiter? x y f(x,y) f(x,y) Secure lottery with penalties Can secure computation replace a trusted third party?

  14. This Work • Formal framework capturing financial transactions • Formal specification of ideal functionalities • “Claim-or-refund” transaction functionality FCR • Secure computation with penalties • Secure lottery with penalties • Efficient multiparty protocols in FCRhybrid model • Linear number of calls to FCR • Linear rounds

  15. Related Work • Bitcoin lottery in the penalty model • 2-party [BB13] • Multiparty [ADMM13a] • Secure computation in the penalty model using Bitcoin • 2-party [ADMM13b] (Concurrent work) • Somewhat ad-hoc construction/analysis • Security not proven using the simulation paradigm • No multiparty secure computation in the penalty model • Multiparty lottery [ADMM13a] requires quadratic number of Bitcoin transactions

  16. This Work • Formal framework capturing financial transactions • Formal specification of ideal functionalities • “Claim-or-refund” transaction functionality FCR • Secure computation with penalties • Secure lottery with penalties • Efficient multiparty protocols in FCRhybrid model • Linear number of calls to FCR • Linear rounds

  17. Simulation Paradigm [GL90,Bea91,MR91,Can95,Can01,Gol04] x y ≈ x y f(x,y) f(x,y) f(x,y) f(x,y) REAL IDEAL Security as emulation of a REAL execution in the IDEAL model R.V.s describing joint dist. of VIEW of adversary and output of honest parties   ≈ REAL IDEAL

  18. Modular Design & Sequential Composition [Can00,Can01] IDEAL ≈ HYBRID ≈ REAL ≈

  19. Universal Composition [PSW00,PW00,PW01,Can01] • Interactive distinguisher • Concurrent executions Environment No notion of ‘coins’ ≈ REAL IDEAL

  20. Defining Coins A Minimal Notion • Atomic entities • Indistinguishable from one another • (Unique) owner possesses given coin • Ownership changes upon transfer • Notation: coins(x) • coins(x) + coins(y) = coins(x + y) • coins(x) - coins(y) = coins(x - y)

  21. Security with Coins • Wallets & Safes • Used by parties to store coins • Safes store coins in current use • Environment has power to create new coins • Can add/subtract coins from both honest & corrupt parties’ wallets during protocol • Does not have access to honest parties’ safes • Adversary does not have power to create new coins • But has full access to corrupt parties’ wallets & safes • VIEWs of environment/adversary include distribution of coins

  22. Standard Security Definitions ≈ REAL IDEAL

  23. Security with Coins ≈ REAL IDEAL

  24. Transaction functionality HYBRID Unfair ideal IDEAL Fair ideal ≈ • “Straightline” simulation in hybrid model • No rewinding wrt coins or crypto primitives

  25. This Work • Formal framework capturing financial transactions • Formal specification of ideal functionalities • “Claim-or-refund” transaction functionality FCR • Secure computation with penalties • Secure lottery with penalties • Efficient multiparty protocols in FCRhybrid model • Linear number of calls to FCR • Linear rounds

  26. Claim-or-Refund Functionality Implicit in [BB13,Max13] FCR • Accepts from “sender” • Deposit: coins(x) • Time bound:  • Circuit:  • Designated “receiver” can claim this deposit • Produce witness T that satisfies  • Within time  • If claimed, then witness revealed to ALL parties • Else coins(x) returned to sender T ,  • Efficient realization via Bitcoin • Bitcoin scripts & timelocks Allows realization in & across different models

  27. Secure Computation with Penalties • Honest parties submit • Inputs • Deposit: coins(d) • Ideal adversary submits • Inputs of corrupt parties • Penalty deposit: coins(x) • Functionality Ff* does: • Return coins(d) to each honest party • Deliver output to Siffx = hq where h = #honest parties • If S returns abort, send coins(q) to each honest party • If S returns continue, send output to each honest party and return coins(x) to S • If x != hq, then send output to all parties Ff* q = penalty amount

  28. Secure Lottery with Penalties • Honest parties submit • Deposit: coins(d) • Ideal adversary submits • Deposit: coins(x+ tq/n) • Functionality Flot* does: • Pick lottery winner r* at random from {1,…,n} • Return coins(d-q/n) to each honest party • Send r* to Siffx = hq where h = #honest parties • If S returns abort, then • Send coins(q+q/n) to each honest party • Return coins(tq/n) to S • If S returns continue or if x != hq,then send • r* to each honest party and return coins(x) to S • Send coins(q) to Pr* Flot* n = number of parties q = penalty amount & lottery pot

  29. This Work • Formal framework capturing financial transactions • Formal specification of ideal functionalities • “Claim-or-refund” transaction functionality FCR • Secure computation with penalties • Secure lottery with penalties • Efficient multiparty protocols in FCRhybrid model • Linear number of calls to FCR • Linear rounds

  30. Strategy Reduce fair secure computation to fair reconstruction Use strategy for both MPC & lottery • Hybrid model with functionality f ’ • Computes output of f, say z • Secret share z into n additive shares sh1,…,shn • Computes commitments on shares • ci = com(shi; wi) for every i • Delivers output: ({c1,…,cn}, Ti = (shi, wi)) to party Pi Ff’ • For straightline simulation use “honest-binding equivocal commitments” [GKKZ11] • Realizable using OWF [Nao91], DDH [Ped91]

  31. Two Party Fair Reconstruction denotes P2 must reveal witness T = (sh,w) within time  to claim coins(q) from P1 • Secure computation with penalties • Honest parties never have to lose coins • If a party aborts after learning the output then every honest party is compensated • “Abort” Attack • P2 aborts without making its deposit but claims P1’s deposit • Honest P1 loses money (although it learns output)

  32. Two Party Fair Reconstruction denotes P2 must reveal witness T = (sh,w) within time  to claim coins(q) from P1 • Secure computation with penalties • Honest parties never have to lose coins • If a party aborts after learning the output then every honest party is compensated • Deposits made top to bottom • Claims made in reverse direction • If P1 claims the 2nd deposit, then P2 can always claim the 1st

  33. Three Party Fair Reconstruction denotes P2 must reveal witness T = (sh,w) within time  to claim coins(q) from P1 • Secure computation with penalties • Honest parties never have to lose coins • If a party aborts after learning the output then every honest party is compensated • Malicious Coalitions • Coalition of P1 and P2 obtain T3 from P3 • Then P2 does not claim 1st transaction • P1, P2 learn output but P3 is not compensated

  34. Three Party Fair Reconstruction denotes P2 must reveal witness T = (sh,w) within time  to claim coins(q) from P1 • Secure computation with penalties • Honest parties never have to lose coins • If a party aborts after learning the output then every honest party is compensated • P2 claims twice the penalty amount • Sufficient to deal with malicious coalition of P1, P3

  35. Multiparty “Ladder” Protocol Order of deposits/claims • Roof deposits made simultaneously • Ladder deposits made one after the other • Ladder claims in reverse • Roof claims at the end Roof High-level Intuition • At the end of ladder claims, all parties except Pn have “evened out” • If Pn does not make roof claims then honest parties get coins(q) via roof refunds • Else Pn “evens out” Ladder

  36. “Ladder” Protocol for Lottery Ridge Roof Order of deposits/claims • Ridge & Roof deposits made simultaneously • Ladder deposits made one after the other • Ladder claims in reverse • Ridge & Roof claims at the end Ladder

  37. “Ladder” Protocol for Lottery Ridge Roof High-level Idea • After ladder claims:Pn has paid all other parties coins(q) to learn lottery outcome • After roof claims: Pn pays coins(q) to lottery winner • After ridge claims: Pnreceives coins(q/n) from each party Ladder

  38. Future Directions • Fully rigorous framework for capturing financial transactions • Is our minimal model the right model? • Prove a composition theorem? • Better understanding of functionalities offered by Bitcoin • Abstraction of other interesting Bitcoin transactions • More applications • Anonymous lotteries • Penalizing any protocol deviation (suggested by Yuval Ishai)

  39. Killer App for MPC? People don’t seem to care much about privacy… MPC has to provide something that people really need right now… • Fair exchange? • Fair lottery? • REAL poker over the internet? Thank You!! ePrint 2014/129

  40. Thank You!

  41. The research leading to these results has received funding from the European Union's Seventh Framework Programme(FP7/2007-2013)under grant agreement no. 259426 – ERC – Cryptography and Complexity

  42. Ladder Protocols • Multiparty fair secure computation & fair lottery • Provably Secure • Also, more efficient than prior ad-hoc constructions [ADMM13,14]