This document discusses smart contracts and applications, focusing on secure multiparty computations using Bitcoin contracts. It describes how Bitcoin contracts can be used to simulate coin tossing and other multiparty computations without requiring a trusted third party. Criminal uses of smart contracts, such as ordering a murder, are also discussed, along with potential solutions like authenticated data feeds. Formal modeling of contracts using timed automata is presented as a way to analyze complicated contracts.
1. 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
2. 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
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
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!
5. Example 1: coin tossing
bfa1406343bb49
ga63w234349aa
bfa144534555d9
output: Y Y
where Y =
with probability 1/2
with probability 1/2
6. 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
7. 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 )
9. 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:
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
• 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
13. Example: Two party lotteries
• a random party earns 1
BTC
• the other one looses 1
BTC
bfa1406343bb49
ga63w234349aa
bfa144534555d9
14. Looks similar to the “coin-
tossing problem”.
bfa1406343bb49
ga63w234349aa
bfa144534555d9
output: Y Y
where Y =
with probability 1/2
with probability 1/2
15. How to solve the coin-tossing problem?
Idea
Remember the old
game:
rock-paper-scissors?
17. 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
18. 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)
19. 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
20. How to guarantee this?
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 (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)
23. 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
24. 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...
25. 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)
26. 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:
27. 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
28. This is exactly what we need for our
hash-based commitments
A R
H
H(A,R)
X = (A,R)
29. 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 =
30. 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.
31. 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
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: 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
34. 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
35. 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
36. 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
37. Possible solution
use a trusted third party.
(for example: a judge)
in case of
disagreement
judge
39. 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!
40. So: how can Alice order a murder
of Carol by Bob using smart
contracts?
41. “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?
42. 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
43. How a such a “proof” can look like?
Examples:
• signed article from some press agency,
• “authenticated data feed”,
• several sources combined
44. Example
1,000 BTC
if Bob provides
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 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.
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 prevent it?
Banning Ethereum? Probably a bad idea.
Banning Authenticated Data Feeds? Maybe…
49. 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
50. 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.
51. 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
