how to use bitcoin to design fair protocols

How to Use Bitcoin to Design Fair Protocols

Iddo Bentov (Technion) Ranjit Kumaresan (Technion)ePrint 2014/129

x

f (x,y)

y

f (x,y)

Secure Computation

• Most general problem in cryptography• Feasibility results [Yao86,GMW87,…]• Moving fast from theory to practice

Secure Computation

• Privacy• Correctness• Input independence• Fairness

Ideally…

x yf (x,y) f (x,y)

Best Possible Security

x

f (x,y)

y

f (x,y)≈

Protocol for secure

computation emulates a

trusted party

Fairness in Secure Computation

• 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]

f (x,y)

Fair Exchange[Rab81,BGMR85,ASW97,ASW98,BN00,….]

Contract signing:• Two parties want to sign a contract• Neither wants to commit first

– The other signer could be malicious…

• E.g., contract signing, digital media• Special case of secure computation

– Authenticity & fairness

Fair Exchange[Rab81,BGMR85,ASW97,ASW98,BN00,….]

Fair exchange is impossible

[Cle86,PG99,BN00]

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

Workarounds II

• Optimistic model [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 arbiterf (x,y)

Bad guys get away with cheating

Workarounds III

• Penalty model [ASW00,MS01,CLM07,Lin08,KL10]

– Deviating party pays monetary penalty to honest party

• Bad guys get away with cheatinglose money!

“Secure computation with penalties”

Penalty Model

Ideally…• Decentralized system;

no trusted third party• Widely adopted

• “Legally enforceable fairness” [Lin08]

– Requires central trusted bank

• “Usable optimistic exchange” [ASW00,MS01,CLM07,KL10]

– Requires trusted arbiter (+ e-cash)

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

Bitcoin [Nak08]

• Wide variety of transactions– Expressive via 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

Secure computation with penalties

Secure lottery with penalties

Can Bitcoin replace a trusted bank/arbiter?

Can secure computation replace a trusted third party?

x

f (x,y)

y

f (x,y)

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 FCR hybrid model– Linear number of calls to FCR

– Linear rounds

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





– Linear rounds

Simulation Paradigm

≈x

f (x,y)

y

f (x,y)

x yf (x,y) f (x,y)

REAL IDEAL

REAL IDEAL≈R.V.s describing joint dist. of VIEW of

adversary and output of honest parties

[GL90,Bea91,MR91,Can95,Can01,Gol04]

Security as emulation of a REAL execution in the IDEAL model

≈HYBRID

Modular Design & Sequential Composition [Can00,Can01]

≈≈

REAL

IDEAL

REAL IDEAL

≈

Universal Composition

Interactive distinguisher

• Concurrent executions No notion of ‘coins’

[PSW00,PW00,PW01,Can01]

Environment

Defining Coins• 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)

A Minimal Notion

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

≈REAL IDEAL

Standard Security Definitions

REAL IDEAL

≈

Security with Coins

HYBRID

≈

IDEALTransaction functionality

• “Straightline” simulation in hybrid model– No rewinding wrt coins or crypto primitives

Unfair ideal

Fair ideal




• Efficient multiparty protocols in FCR hybrid model

– Linear number of calls to FCR

– Linear rounds

Claim-or-Refund Functionality• 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 ,

FCR

Efficient realization via Bitcoin• Bitcoin scripts & timelocks

Allows realization in & across different models

Implicit in [BB13,Max13]

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 S iff x = 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

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 S iff x = 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 partiesq = penalty amount

& lottery pot





– Linear rounds

Strategy

• 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]

Reduce fair secure computation to fair

reconstruction

Use strategy for both MPC & lottery

Two Party Fair Reconstruction

“Abort” Attack• P2 aborts without making its

deposit but claims P1’s deposit• Honest P1 loses money

(although it learns output)

denotesP2 must reveal witness T = (sh,w) within time to claim coins(q) from P1


• Honest parties never have to lose coins

• If a party aborts after learning the output then every honest party is compensated

Two Party Fair Reconstruction

• Deposits made top to bottom• Claims made in reverse direction• If P1 claims the 2nd deposit, then P2

can always claim the 1st





Three Party Fair Reconstruction

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





Three Party Fair Reconstruction

• P2 claims twice the penalty amount• Sufficient to deal with

malicious coalition of P1, P3





Multiparty “Ladder” Protocol

Ladd

erR

oof

Order of deposits/claims• Roof deposits made

simultaneously• Ladder deposits made one

after the other• Ladder claims in reverse• Roof claims at the end

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” Protocol for Lottery

Ladd

erR

oof

Rid

ge

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” Protocol for Lottery

Ladd

erR

oof

Rid

ge

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: Pn receives coins(q/n) from each party

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)

People don’t seem to care much about privacy…

MPC has to provide something that people really need right now…

Killer App for MPC?

• Fair exchange?• Fair lottery?• REAL poker over the

internet?

Thank You!! ePrint 2014/129

Thank You!

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

Ladder Protocols

• Multiparty fair secure computation & fair lottery

• Provably Secure

• Also, more efficient than prior ad-hoc constructions [ADMM13,14]

how to use bitcoin to design fair protocols

Documents