How to Use Bitcoin to Design Fair Protocols

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]