how to use bitcoin to incentivize correct computations ranjit kumaresan (mit) iddo bentov (technion)...
TRANSCRIPT
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!!!