Smart Contracts and Applications
(part II)
Stefan Dziembowski
University of Warsaw
Workshop on Bitcoin, Introduction to Cryptocurrencies,
Kfar Maccabiah, Ramat Gan, Israel, June 6-7, 2016
Plan
1. Secure multiparty computations +
Bitcoin contracts
2. Criminal use of smart contract
(“How to order a murder using
cryptocurrencies?”)
3. Formal modelling of contracts
This part
Based on
• Andrychowicz, D., Malinowski, Mazurek: Secure
Multiparty Computations on Bitcoin. IEEE
Symposium on Security and Privacy 2014
• Andrychowicz, D., Malinowski, Mazurek : Secure
Multiparty Computations on Bitcoin. BITCOIN
Workshop 2014
• Andrychowicz, D., Malinowski, Mazurek : Secure
multiparty computations on Bitcoin. Commun. ACM
59(4) 2016
Independent work by: Adam Back, Iddo Bentov, Ranjit
Kumaresan, Tal Moran.
Multiparty Computation (MPC)
protocols
Protocols where the users of the protocol don’t trust
each other, but nevertheless
they want to achieve a common goal
bfa1406343bb49
ga63w234349aa
bfa144534555d9
Alice Bob
I don’t trust Bob I don’t trust Alice
common goal achieved!
Example 1: coin tossing
bfa1406343bb49
ga63w234349aa
bfa144534555d9
output: Y Y
where Y =
with probability 1/2
with probability 1/2
Example 2: marriage proposal
bfa1406343bb49
ga63w234349aa
bfa144534555d9
output: Y Y
input: A =
1 if Alice loves Bob
0 otherwise
B =
1 if Bob loves Alice
0 otherwise
where: Y = A ∧ B
Example 3: set operations
bfa1406343bb49
ga63w234349aa
bfa144534555d9
output: Y Y
input: A = a set of Alice’s friends B = a set of Bob’s friends
where: Y = A ∩ B (or Y = A ∪B )
Possible applications
• cloud computing
• online auctions
• e-voting
But is it possible to construct such protocols?
With a “trusted third party” – it’s easy
A B
Y Y
bfa1406343bb49
ga63w234349aa
bfa144534555d9
But can we do it without a trusted third party?
In other words: can we “simulate” the ideal world in the real world?
ideal world:
real world:
Every can be “simulated” in a secure way.
So, can we construct such
protocols?
Manuel
Blum
Andrew
Yao
Oded
Goldreich
Silvio
Micali
Avi
Widgerson
Answer: Yes! (under some assumptions and with
certain limitations)
The limitations
• lack of fairness when there is no
honest majority
(we will explain it in a moment),
• no way to force the parties to provide
true input,
• and to respect the outcome.
partial
remedies
exist
beyond
the
scope of
crypto
Our idea
Deal with these
problems using
Bitcoin
Example: Two party lotteries
• a random party earns 1
BTC
• the other one looses 1
BTC
bfa1406343bb49
ga63w234349aa
bfa144534555d9
Looks similar to the “coin-
tossing problem”.
bfa1406343bb49
ga63w234349aa
bfa144534555d9
output: Y Y
where Y =
with probability 1/2
with probability 1/2
How to solve the coin-tossing problem?
Idea
Remember the old
game:
rock-paper-scissors?
draw
Alice
wins
Bob
wins
Bob
wins
draw
Alice
wins
Alice
wins
Bob
wins
draw
Alice
Bob
Let’s simplify this game
In other words: Alice wins iff A xor B = 0.
A=0 A=1
B=0
Alice
wins
Bob
wins
B=1
Bob
wins
Alice
wins
Alice
Bob
Another way to look at it
Alice
has an input B
Bob
has an input A
they should jointly compute
x = A xor B
(in a secure way)
What to do?
Problem:
A and B should be sent at the same time
(e.g. if A is sent before B then a malicious Bob can
set B := x xor A, where x is chosen by him).
x = A xor B x = A xor B
random bit A
random bit B
How to guarantee this?
Seems hard:
the internet is not synchronous...
A solution:
bit commitments
Commitment schemes – an intuition
Alice sends a locked box to Bob
a bit A
A
Alice can later send the key to Bob
A
[binding] from now Alice cannot change A,
[hiding] but Bob doesn’t know A
Alice “commits
herself to A”
Alice “opens the
commitment”
Hash-based commitments
hash-based (in the random oracle model):
H – hash function (eg. SHA256)
• to commit to A ∈ {0,1} take random R∈ {0,1}k and
send H(A,R)
• to open A send (A,R).
A R
H
H(A,R)
H(A,R)
(A,R)
How does it solve the coin-
flipping problem?
chooses a
random bit A
commits to A
sends B chooses a
random bit B
opens A
output
A xor B
output
A xor B
A
Problem 1
How to force Alice to open the commitment?
commits to A
sends B
opens A
This is precisely the lack of fairness problem.
It’s inherent to most of the interesting MPC protocols...
Problem 2
commits to A
sends B
opens A
You lost So what?
This is the problem of forcing the parties to respect
the output.
Even more inherent (it is present also in the “ideal
world” solution)
Idea: force the parties to open their
commitments using the “deposits”
commits to bit A
transaction commit
• has value 1 BTC
• can be redeemed by Alice
• claiming the transaction requires revealing A
if Alice didn’t redeem commit, then
Bob can do it after 1 day
deposit:
How to implement it?
We use the Bitcoin scripting language.
Remember the hash-locked transactions from the last
lecture?
H – hash function
Let Y := H(X)
A Y-hash-locked transaction from A to B can be redeemed
only by publishing X:
T2 =
can be spent using B’s
signature and X such that
Y = H(X)
A’s
signature
T1
1
BTC
This is exactly what we need for our
hash-based commitments
A R
H
H(A,R)
X = (A,R)
How can Alice commit to A?
can be spent using Alice’s
signature and (A,X) such
that Y = H(A,X)
or
both signatures of
Alice and Bob
Alice’s
signature
T
1
BTC
post on the blockchain:
send to Bob a Refund transaction:
Commit =
some earlier
transaction of Alice
can be spent using Bob’s
signature after 1 day
Alice’s signature
Commit
1
BTCRefund =
This solves the problem of the lack of
fairness!
commits with a Bitcoin-
based commitment to A
sends B
opens A
If Alice does not open
her commitment
within 1 day then Bob
can get her 1 BTC by
posting the Refund
transaction with his
signature
Otherwise she gets
her 1 BTC back.
What about the problem of
respecting the outcome?
This can also be solved. Main idea:
commits with a Bitcoin-based commitment to A
commits with a Bitcoin-based commitment to B
a transaction that takes the
opening of the committed values
and “decides” who won
prob. 1/2
The results of [Andrychowicz
et al]
Any two-party non-reactive functionality can be
“simulated” in this way.
The simulation can enforce the financial
consequences.
Generalized to multiparty reactive functionalities
in [Kumaresan, Moran, Bentov].
An example: selling secret
information
“set-sum with rewards for each record”
bfa1406343bb49
ga63w234349aa
bfa144534555d9
output: A ∪B A ∪B
plus a money transfer between Alice and Bob depending
on the number of new records that the parties learned
Plan
1. Secure multiparty computations +
Bitcoin contracts
2. Criminal use of smart contract
(“How to order a murder using
cryptocurrencies?”)
3. Formal modelling of contracts
This part
We show that cryptographic currencies (like
Bitcoin) have features that allow to make such
“crime contracts”
Partly based on:
Ari Juels, Ahmed E. Kosba, Elaine Shi
The Ring of Gyges: Using Smart Contracts
for Crime
How to order a murder?
I want murdered.
I can do it for
1,000,000 USD.
So do it, and then I will pay you.
No, pay first.
No, kill first.
...
Alice
Bob
Carol
Possible solution
use a trusted third party.
(for example: a judge)
in case of
disagreement
judge
Problem
They cannot go to a judge with such a contract!
judge
Idea
Maybe we could use
some modern
technology?
What if we make a
payment in
Bitcoin?
But Bitcoin is just another currency… How can it
make any difference?
Answer: use smart contracts!
So: how can Alice order a murder
of Carol by Bob using smart
contracts?
“Murder contract”
1,000 BTC
if Bob provides
a proof that Carol is
murdered during the
next hour
Alice
Bob
Question: what if Bob is just lucky and Carol was murdered by
someone else?
Solution: add some details
1,000 BTC
if Bob provides
a proof that Carol is
murdered during the
next hour using a .44
Remington Magnum
gun
Alice
Bob
How a such a “proof” can look like?
Examples:
• signed article from some press agency,
• “authenticated data feed”,
• several sources combined
Example
1,000 BTC
if Bob provides
an article containing texts:
• “Carol was murdered”
• “.44 Remington Magnum
gun”
signed by Associated Press
Alice
Bob
Two technical problems
1. such conditions are impossible to express using
Bitcoin syntax
2. a separate “contract” is needed for every potential
hitman
Solution:
a currency designed for doing contracts.
Features
• has a concept of a “contract’’ that can be posted on the
public register, and give money to anyone who
provides some “solution”
• allows to create arbitrarily complicated contracts.
Some “crime contracts” do not require
“authenticated data feeds”
Example: stealing secrets
In particular: cryptographic keys.
(remember the
“𝑝 and 𝑞 such that 𝑝⋅𝑞=1591“
contract?)
Another example: selling zero day exploits.
How to prevent it?
Banning Ethereum? Probably a bad idea.
Banning Authenticated Data Feeds? Maybe…
Plan
1. Secure multiparty computations +
Bitcoin contracts
2. Criminal use of smart contract
(“How to order a murder using
cryptocurrencies?”)
3. Formal modelling of contracts
Complicated contracts become tricky
to analyze.
A formal model for contracts is needed.
A recent proposal:
A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou. Hawk:
The Blockchain Model of Cryptography and Privacy-
Preserving Smart Contracts. 2015.
Can we do it automatically?
[Andrychowicz, D., Malinowski, Mazurek, Modeling
Bitcoin Contracts by Timed Automata, 2014]:
Yes! (to a certain extent)
The general idea:
model a contract as a
timed automaton
use the UPPAAL tool
to verify its properties
yes/no
Example: an automaton modelling one
party in the timed commitment
scheme:
©2016 by Stefan Dziembowski. Permission to make digital or hard copies of part or
all of this material is currently granted without fee provided that copies are made
only for personal or classroom use, are not distributed for profit or commercial
advantage, and that new copies bear this notice and the full citation.

Smart contracts and applications part II

  • 1.
    Smart Contracts andApplications (part II) Stefan Dziembowski University of Warsaw Workshop on Bitcoin, Introduction to Cryptocurrencies, Kfar Maccabiah, Ramat Gan, Israel, June 6-7, 2016
  • 2.
    Plan 1. Secure multipartycomputations + Bitcoin contracts 2. Criminal use of smart contract (“How to order a murder using cryptocurrencies?”) 3. Formal modelling of contracts
  • 3.
    This part Based on •Andrychowicz, D., Malinowski, Mazurek: Secure Multiparty Computations on Bitcoin. IEEE Symposium on Security and Privacy 2014 • Andrychowicz, D., Malinowski, Mazurek : Secure Multiparty Computations on Bitcoin. BITCOIN Workshop 2014 • Andrychowicz, D., Malinowski, Mazurek : Secure multiparty computations on Bitcoin. Commun. ACM 59(4) 2016 Independent work by: Adam Back, Iddo Bentov, Ranjit Kumaresan, Tal Moran.
  • 4.
    Multiparty Computation (MPC) protocols Protocolswhere the users of the protocol don’t trust each other, but nevertheless they want to achieve a common goal bfa1406343bb49 ga63w234349aa bfa144534555d9 Alice Bob I don’t trust Bob I don’t trust Alice common goal achieved!
  • 5.
    Example 1: cointossing bfa1406343bb49 ga63w234349aa bfa144534555d9 output: Y Y where Y = with probability 1/2 with probability 1/2
  • 6.
    Example 2: marriageproposal bfa1406343bb49 ga63w234349aa bfa144534555d9 output: Y Y input: A = 1 if Alice loves Bob 0 otherwise B = 1 if Bob loves Alice 0 otherwise where: Y = A ∧ B
  • 7.
    Example 3: setoperations bfa1406343bb49 ga63w234349aa bfa144534555d9 output: Y Y input: A = a set of Alice’s friends B = a set of Bob’s friends where: Y = A ∩ B (or Y = A ∪B )
  • 8.
    Possible applications • cloudcomputing • online auctions • e-voting But is it possible to construct such protocols?
  • 9.
    With a “trustedthird party” – it’s easy A B Y Y bfa1406343bb49 ga63w234349aa bfa144534555d9 But can we do it without a trusted third party? In other words: can we “simulate” the ideal world in the real world? ideal world: real world:
  • 10.
    Every can be“simulated” in a secure way. So, can we construct such protocols? Manuel Blum Andrew Yao Oded Goldreich Silvio Micali Avi Widgerson Answer: Yes! (under some assumptions and with certain limitations)
  • 11.
    The limitations • lackof fairness when there is no honest majority (we will explain it in a moment), • no way to force the parties to provide true input, • and to respect the outcome. partial remedies exist beyond the scope of crypto
  • 12.
    Our idea Deal withthese problems using Bitcoin
  • 13.
    Example: Two partylotteries • a random party earns 1 BTC • the other one looses 1 BTC bfa1406343bb49 ga63w234349aa bfa144534555d9
  • 14.
    Looks similar tothe “coin- tossing problem”. bfa1406343bb49 ga63w234349aa bfa144534555d9 output: Y Y where Y = with probability 1/2 with probability 1/2
  • 15.
    How to solvethe coin-tossing problem? Idea Remember the old game: rock-paper-scissors?
  • 16.
  • 17.
    Let’s simplify thisgame In other words: Alice wins iff A xor B = 0. A=0 A=1 B=0 Alice wins Bob wins B=1 Bob wins Alice wins Alice Bob
  • 18.
    Another way tolook at it Alice has an input B Bob has an input A they should jointly compute x = A xor B (in a secure way)
  • 19.
    What to do? Problem: Aand B should be sent at the same time (e.g. if A is sent before B then a malicious Bob can set B := x xor A, where x is chosen by him). x = A xor B x = A xor B random bit A random bit B
  • 20.
    How to guaranteethis? Seems hard: the internet is not synchronous... A solution: bit commitments
  • 21.
    Commitment schemes –an intuition Alice sends a locked box to Bob a bit A A Alice can later send the key to Bob A [binding] from now Alice cannot change A, [hiding] but Bob doesn’t know A Alice “commits herself to A” Alice “opens the commitment”
  • 22.
    Hash-based commitments hash-based (inthe random oracle model): H – hash function (eg. SHA256) • to commit to A ∈ {0,1} take random R∈ {0,1}k and send H(A,R) • to open A send (A,R). A R H H(A,R) H(A,R) (A,R)
  • 23.
    How does itsolve the coin- flipping problem? chooses a random bit A commits to A sends B chooses a random bit B opens A output A xor B output A xor B A
  • 24.
    Problem 1 How toforce Alice to open the commitment? commits to A sends B opens A This is precisely the lack of fairness problem. It’s inherent to most of the interesting MPC protocols...
  • 25.
    Problem 2 commits toA sends B opens A You lost So what? This is the problem of forcing the parties to respect the output. Even more inherent (it is present also in the “ideal world” solution)
  • 26.
    Idea: force theparties to open their commitments using the “deposits” commits to bit A transaction commit • has value 1 BTC • can be redeemed by Alice • claiming the transaction requires revealing A if Alice didn’t redeem commit, then Bob can do it after 1 day deposit:
  • 27.
    How to implementit? We use the Bitcoin scripting language. Remember the hash-locked transactions from the last lecture? H – hash function Let Y := H(X) A Y-hash-locked transaction from A to B can be redeemed only by publishing X: T2 = can be spent using B’s signature and X such that Y = H(X) A’s signature T1 1 BTC
  • 28.
    This is exactlywhat we need for our hash-based commitments A R H H(A,R) X = (A,R)
  • 29.
    How can Alicecommit to A? can be spent using Alice’s signature and (A,X) such that Y = H(A,X) or both signatures of Alice and Bob Alice’s signature T 1 BTC post on the blockchain: send to Bob a Refund transaction: Commit = some earlier transaction of Alice can be spent using Bob’s signature after 1 day Alice’s signature Commit 1 BTCRefund =
  • 30.
    This solves theproblem of the lack of fairness! commits with a Bitcoin- based commitment to A sends B opens A If Alice does not open her commitment within 1 day then Bob can get her 1 BTC by posting the Refund transaction with his signature Otherwise she gets her 1 BTC back.
  • 31.
    What about theproblem of respecting the outcome? This can also be solved. Main idea: commits with a Bitcoin-based commitment to A commits with a Bitcoin-based commitment to B a transaction that takes the opening of the committed values and “decides” who won prob. 1/2
  • 32.
    The results of[Andrychowicz et al] Any two-party non-reactive functionality can be “simulated” in this way. The simulation can enforce the financial consequences. Generalized to multiparty reactive functionalities in [Kumaresan, Moran, Bentov].
  • 33.
    An example: sellingsecret information “set-sum with rewards for each record” bfa1406343bb49 ga63w234349aa bfa144534555d9 output: A ∪B A ∪B plus a money transfer between Alice and Bob depending on the number of new records that the parties learned
  • 34.
    Plan 1. Secure multipartycomputations + Bitcoin contracts 2. Criminal use of smart contract (“How to order a murder using cryptocurrencies?”) 3. Formal modelling of contracts
  • 35.
    This part We showthat cryptographic currencies (like Bitcoin) have features that allow to make such “crime contracts” Partly based on: Ari Juels, Ahmed E. Kosba, Elaine Shi The Ring of Gyges: Using Smart Contracts for Crime
  • 36.
    How to ordera murder? I want murdered. I can do it for 1,000,000 USD. So do it, and then I will pay you. No, pay first. No, kill first. ... Alice Bob Carol
  • 37.
    Possible solution use atrusted third party. (for example: a judge) in case of disagreement judge
  • 38.
    Problem They cannot goto a judge with such a contract! judge
  • 39.
    Idea Maybe we coulduse some modern technology? What if we make a payment in Bitcoin? But Bitcoin is just another currency… How can it make any difference? Answer: use smart contracts!
  • 40.
    So: how canAlice order a murder of Carol by Bob using smart contracts?
  • 41.
    “Murder contract” 1,000 BTC ifBob provides a proof that Carol is murdered during the next hour Alice Bob Question: what if Bob is just lucky and Carol was murdered by someone else?
  • 42.
    Solution: add somedetails 1,000 BTC if Bob provides a proof that Carol is murdered during the next hour using a .44 Remington Magnum gun Alice Bob
  • 43.
    How a sucha “proof” can look like? Examples: • signed article from some press agency, • “authenticated data feed”, • several sources combined
  • 44.
    Example 1,000 BTC if Bobprovides an article containing texts: • “Carol was murdered” • “.44 Remington Magnum gun” signed by Associated Press Alice Bob
  • 45.
    Two technical problems 1.such conditions are impossible to express using Bitcoin syntax 2. a separate “contract” is needed for every potential hitman Solution: a currency designed for doing contracts.
  • 46.
    Features • has aconcept of a “contract’’ that can be posted on the public register, and give money to anyone who provides some “solution” • allows to create arbitrarily complicated contracts.
  • 47.
    Some “crime contracts”do not require “authenticated data feeds” Example: stealing secrets In particular: cryptographic keys. (remember the “𝑝 and 𝑞 such that 𝑝⋅𝑞=1591“ contract?) Another example: selling zero day exploits.
  • 48.
    How to preventit? Banning Ethereum? Probably a bad idea. Banning Authenticated Data Feeds? Maybe…
  • 49.
    Plan 1. Secure multipartycomputations + Bitcoin contracts 2. Criminal use of smart contract (“How to order a murder using cryptocurrencies?”) 3. Formal modelling of contracts
  • 50.
    Complicated contracts becometricky to analyze. A formal model for contracts is needed. A recent proposal: A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou. Hawk: The Blockchain Model of Cryptography and Privacy- Preserving Smart Contracts. 2015.
  • 51.
    Can we doit automatically? [Andrychowicz, D., Malinowski, Mazurek, Modeling Bitcoin Contracts by Timed Automata, 2014]: Yes! (to a certain extent) The general idea: model a contract as a timed automaton use the UPPAAL tool to verify its properties yes/no
  • 52.
    Example: an automatonmodelling one party in the timed commitment scheme:
  • 53.
    ©2016 by StefanDziembowski. Permission to make digital or hard copies of part or all of this material is currently granted without fee provided that copies are made only for personal or classroom use, are not distributed for profit or commercial advantage, and that new copies bear this notice and the full citation.