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 ComputationApplication II

x

f (x,y)

y

f (x,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 ComputationApplication II

Fair ExchangeApplication 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 ExchangeApplication 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

Maker Collector

Miner

Bitcoin BountiesApplication IV

Miners can steal the reward!!

Bitcoin BountiesApplication 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 ,

FCR

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

,

FCR

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 vkHonest server not paid for output

Compiling a public VC scheme

SolutionSecure computation to emulate KeyGen

T ,

FCR

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

• 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

GCGC

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

GCGC2GCGC1

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

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 sh1,…,shn

– Computes commitments ci = SHA(shi; wi) for every i

– Delivers output: ({c1,…,cn}, Ti = (shi, wi)) to party Pi

Reduce fair secure computation to fair reconstruction

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

“Ladder” Protocol [BK14]

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”

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

MakerWEnc( f, sk), bounty claimed

by signing with skCollector

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