How to Use Bitcoin to Incentivize Correct Computations

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

Bitcoin [Nak 08] • 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” Applications • • Verifiable computation Efficient secure computation Fair exchange Bitcoin bounties – More privacy/security – Reduced “validation complexity” • Incentivization mechanisms fairly general – For other models, see [GM 99, AM 12, GRV 14, …]

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 Do. S, 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

Application I 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 [GMR 85, BFL 91, Mic 94, GKR 08, GGP 10, BCCT 12, …]

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 II Efficient Secure Computation • Threat models – Semi-honest – Malicious x y f (x, y) • Moving MPC from theory to practice – Major research direction – Semi-honest nearly practical – Malicious? • In 2007: 680 x semi-honest [LP 07] • In 2014: 8 x semi-honest [HKKKM 14, LR 14] (amortized cost)

Application II Efficient Secure Computation • Dual execution protocols [MF 06] – – 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

Application III Fair Exchange [Rab 81, BGMR 85, ASW 97, ASW 98, BN 00, …. ]

Application III Fair Exchange • Contract signing – Two parties want to sign a contract – Neither wants to commit first • The other signer could be malicious… Fair exchange is impossible [Cle 86, PG 99, BN 00] • Our contributions: – Fair secure computation in a “penalty model” – Anyone who aborts after learning output pays penalty to all parties

Application IV Bitcoin Bounties Maker Collector Miners can steal the reward!!

Application IV 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 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 Implicit in [Max 11, BBSU 12, BB 13] FCR • Accepts from “sender” S – Deposit: coins(x) – Time bound: – Circuit: , T • 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 Efficient realization via Bitcoin • Bitcoin scripts & timelocks Allows realization in & across different models

Candidate realization in Bitcoin Implicit in [Max 11, BBSU 12] • S creates cr. TX that spends s. TX (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 cr. TX to S after time • Finally S broadcasts cr. TX to the Bitcoin network • The steps above can be implemented safely since – S needs only to send Hash(cr. TX) to R – R can use fresh signing keys in this protocol

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 FCR , T • Set u(y) = 1 iff f (u) = y – Validation comp. = | f |

Fair Verifiable Computation Compiling a public VC scheme FCR Public VC • ( ek, vk ) <- Key. Gen( f ) • ( y, pf ) <- Compute( ek, u ) • 0/1 <- Verify( vk, u, y, pf ) Malicious client supplies incorrect vk Honest server not paid for output Solution Secure computation to emulate Key. Gen , T • 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

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 FCR 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

Efficient Secure Computation • Dual execution protocols [MF 06] – – 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: GC Garbled circuits Transfer input encodings Return output encodings GC Malicious Alice can learn Bob’s input!! • Method to compute over encrypted data • Compute with input encodings to obtain output encodings

Dual Execution To incentivize: GC 1 • Generate encodings and GC from short seed Transfer input encodings – Allows to prove correct behavior via NIZK – Narrows down attack to false functions GC 2 • To claim penalty: Transfer input encodings GC 1 GC GC 2 GC – NIZK for own GC: to prove that party behaved correctly – Proof of leakage: to prove that other party didn’t follow protocol Secure equality test of output encodings; release output only if test passes • Fair secure equality test Malicious party learns at most one bit! • Optimistic: O(1) hash – Malicious party may abort after learning leaked bit – 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 [ADMM 14, BK 14] • Deviating party pays monetary penalty to honest party • Bad guys lose money if they deviate after learning output • Honest parties never lose money Theorem [BK 14]: Fair multiparty secure computation with penalties can be constructed using only claim-or-refund transactions

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

“Ladder” Protocol [BK 14] • Roof deposits made simultaneously • Ladder deposits made one after the other • Ladder claims in reverse • Roof claims at the end Roof Order of deposits/claims • 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 High-level intuition

Multilock Functionality • N-party mechanism (recall FCR was 2 party) – Everybody locks coins in a single transaction – Can redeem own coins by revealing Ti 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 [GGH 13] • ct <- WEnc( f, b ) • b/NULL <- WDec( ct, w ) Maker 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 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!!!