How to Use Bitcoin to Incentivize Correct Computations Ranjit Kumaresan (MIT) Iddo Bentov (Technion) Appeared at CCS 2014

Bitcoin [Nak08] Decentralized digital currency – Provides some level of anonymity (Relatively) widely adopted Lots of recent research activity “Securely” implements a bank Wide variety of transactions – Expressive via Bitcoin “scripts” Wide range of applications – E.g.: Lottery, gambling, auctions,… – Currently done using a “trusted” party

This paper More applications but with… – Reduced trust assumptions – Formal security proofs Bit like “smart contracts” – More privacy/security – Reduced “validation complexity” Incentivization mechanisms fairly general – For other models, see [GM99,AM12,GRV14,…] Applications Verifiable computation Efficient secure computation Fair exchange Bitcoin bounties

Applications Verifiable computation Efficient secure computation Fair exchange Bitcoin bounties

Efficiency Metrics Computation/communication/round complexity – Varies depending on application Validation complexity – Complexity of scripts – Reduced load on the Bitcoin network – Faster validation – Transaction fee proportional to validation complexity Optimistic complexity – Typically expect parties to behave honestly – Optimize for this; not for worst case

Practical Issues Design mechanisms in idealized Bitcoin – Attacks on Bitcoin (e.g., 51%) break our mechanisms Good communication network – No DoS, etc. Extended script support – Currently many opcodes blacklisted – Altcoins with Turing-complete scripts (Ethereum) – Support with increased transaction fees (Cool but) heavy crypto – Garbled circuits, SNARKs, NIZKs, … – Currently impractical but expected to improve

Talk Outline Applications – Model, goal Basic Tools High level overview of constructions

Verifiable Computation Outsourcing computation to the cloud Many incentives for a cloud to cheat – Minimize resource usage – Malicious server! Verify correctness of server computations – Verification cheaper than computation Very well studied [GMR85,BFL91,Mic94,GKR08,GGP10,BCCT12,…] Application I

Verifiable Computation Incentive for the server? – Pay per computation model – Client pays server for output Fairness issues? – Client aborts after learning output, doesn’t pay – Cannot pay ahead of time, server might just not compute! Our contributions – Compile any VC scheme into a “fair” VC scheme Application I

Threat models – Semi-honest – Malicious Moving MPC from theory to practice – Major research direction – Semi-honest nearly practical – Malicious? In 2007: 680 x semi-honest [LP07] In 2014: 8 x semi-honest [HKKKM14,LR14] (amortized cost) Efficient Secure Computation Application II x f (x,y) y

Dual execution protocols [MF06] – 2 x semi-honest – But… leaks 1-bit of information! – Leakage happens only on cheating – Leakage undetected when cheater guesses leaked 1-bit Major problem when considering multiple executions! Our contributions – Punish cheating party whenever leakage detected Punishment corresponds to paying a penalty – Preserve efficiency of Dual-Ex when parties behave honestly Efficient Secure Computation Application II

Fair Exchange Application III [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… Fair Exchange Application III Fair exchange is impossible [Cle86,PG99,BN00] Our contributions: – Fair secure computation in a “penalty model” – Anyone who aborts after learning output pays penalty to all parties

MakerCollector Miner Bitcoin Bounties Application IV Miners can steal the reward!!

Bitcoin Bounties Application IV Maker places bounty on solution of hard problem by sending a single message Collector can collect the bounty – Identity unknown at the time of bounty creation Maker learns solution upon collection Miners can’t collect bounty or learn solution

Talk Outline Applications – Model, goal Basic Tools – Claim-or-refund Transaction functionality High level overview of constructions

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

Candidate realization in Bitcoin S creates crTX that spends sTX (that S controls) to a script that can be redeemed by producing either – Both S’s and R’s signature; or – R’s signature and a valid witness T that satisfies  R signs a transaction that refunds crTX to S after time  Finally S broadcasts crTX to the Bitcoin network The steps above can be implemented safely since – S needs only to send Hash(crTX) to R – R can use fresh signing keys in this protocol Implicit in [Max11,BBSU12]

Talk Outline Applications – Model, goal Basic tools High level overview of constructions – Verifiable computation – Efficient secure computation – Fair secure computation – Bitcoin bounties

Verifiable Computation Weak client outsources computation of f – Client can verify output correctness – Pay per computation model – Client pays server for output Set  u (y) = 1 iff f (u) = y – Validation comp. = | f | T ,  F CR

Fair Verifiable Computation Public VC ( ek, vk ) <- KeyGen( f ) ( y, pf ) <- Compute( ek, u ) 0/1 <- Verify( vk, u, y, pf ) Set  vk,u ( y, pf ) = 1 iff Verify(vk, u, y, pf ) = 1 – Validation comp. = | Verify | – 288 bytes; 9 ms – Optimistic: zero – Prover comp. very high Malicious client supplies incorrect vk Honest server not paid for output Compiling a public VC scheme Solution Secure computation to emulate KeyGen T ,  F CR

Fair Verifiable Computation Incentivizing public VC is possible – But Input/output known to entire Bitcoin network Can incentivize private VC? – Input/output kept private even from server! Similar strategy for compiling private VC schemes – Securely emulate each algorithm except Compute – Client makes F CR deposit after secure emulation of Verify – Does not guarantee pay on computation for server – Validation comp. = hash invocation

Talk Outline Applications – Model, goal Basic tools High level overview of constructions – Verifiable computation – Efficient secure computation – Fair secure computation – Bitcoin bounties

Dual execution protocols [MF06] – 2 x semi-honest – But… leaks 1-bit of information! – Leakage happens only on cheating – Leakage undetected when cheater guesses leaked 1-bit Basic semi-honest garbled circuits protocol: Efficient Secure Computation Transfer input encodings GC Garbled circuits Method to compute over encrypted data Compute with input encodings to obtain output encodings Return output encodings Malicious Alice can learn Bob’s input!!

Dual Execution Transfer input encodings GC1 Transfer input encodings GC2 GC GC2 GC GC1 Secure equality test of output encodings; release output only if test passes Malicious party learns at most one bit! To incentivize: Generate encodings and GC from short seed – Allows to prove correct behavior via NIZK – Narrows down attack to false functions To claim penalty: – NIZK for own GC: to prove that party behaved correctly – Proof of leakage: to prove that other party didn’t follow protocol Fair secure equality test – Malicious party may abort after learning leaked bit Optimistic: O(1) hash – Worst-case: NIZK verification

Talk Outline Applications – Model, goal Basic tools High level overview of constructions – Verifiable computation – Efficient secure computation – Fair secure computation – Bitcoin bounties

Fair Secure Computation Deviating party pays monetary penalty to honest party Bad guys lose money if they deviate after learning output Honest parties never lose money Bad guys lose money if they deviate after learning output Honest parties never lose money Theorem [BK14]: Fair multiparty secure computation with penalties can be constructed using only claim-or-refund transactions [ADMM14, BK14]

Strategy Run secure computation that: – Computes output of f, say z – Secret share z into n additive shares sh 1,…,sh n – Computes commitments c i = SHA(sh i ; w i ) for every i – Delivers output: ({c 1,…,c n }, T i = (sh i, w i )) to party P i Reduce fair secure computation to fair reconstruction Reduce fair secure computation to fair reconstruction denotes P 2 must reveal witness T = (sh,w) within time  to claim coins(q) from P 1 denotes P 2 must reveal witness T = (sh,w) within time  to claim coins(q) from P 1

“Ladder” Protocol [BK14] Ladder Roof 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 P n have “evened out” If P n does not make roof claims then honest parties get coins(q) via roof refunds Else P n “evens out”

Multilock Functionality N-party mechanism (recall F CR was 2 party) – Everybody locks coins in a single transaction – Can redeem own coins by revealing T i within specified time – Upon failure, coins go to other parties Gives constant round fair secure computation

Talk Outline Applications – Model, goal Basic tools High level overview of constructions – Verifiable computation – Efficient secure computation – Fair secure computation – Bitcoin bounties

Bitcoin Bounties Maker places bounty on solution of hard problem by sending a single message Collector can collect the bounty – Identity unknown at the time of bounty creation Maker learns solution upon collection Miners don’t collect bounty or learn solution Bounty ( m, r ) <- Make( f ) c <- Collect( m, w ) 0/1 <- Verify( m, c ) w/NULL <- Extract( c, r ) Properties Correctness: Verify passes for c from w with f (w) = 1 Security (informal): If an eavesdropper can obtain information about w from ( m, c ) then it must already know w before knowing c

Bitcoin Bounties Witness Encryption [GGH13] ct <- WEnc( f, b ) b/NULL <- WDec( ct, w ) Properties Correctness: Dec recovers b iff f (w) = 1 Security (informal): If an eavesdropper can obtain information about b from ct, then it must already know w Maker WEnc( f, sk), bounty claimed by signing with sk Collector Decrypt to get sk; Claim bounty Miners don’t learn witness, can’t steal reward. Maker can learn witness by asking for an NIZK proof for which it generates Setup

Summary How to incentivize correct behavior in: – Verifiable computation – Efficient secure computation – Fair secure computation – Bitcoin bounty mechanism Future directions : – More applications? – Efficiency improvements? THANK YOU!!!