Smart contracts and applications part II

transcript

Smart Contracts and Applications(part II)

Stefan DziembowskiUniversity of Warsaw

Workshop on Bitcoin, Introduction to Cryptocurrencies,Kfar Maccabiah, Ramat Gan, Israel, June 6-7, 2016

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

Example 2: marriage proposal

bfa1406343bb49

ga63w234349aa

bfa144534555d9

output: Y Y

input: A =1 if Alice loves Bob0 otherwise

B =1 if Bob loves Alice0 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

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

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

How to solve the coin-tossing problem?

Remember the old game:

rock-paper-scissors?

drawAlicewins

Bobwins

drawAlicewins

Alicewins

Bobwins

Let’s simplify this game

In other words: Alice wins iff A xor B = 0.

A=0 A=1

B=0Alicewins

Bobwins

B=1Bobwins

Alicewins

Another way to look at it

Alicehas an input B

Bobhas 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

Alice can later send the key to Bob

[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).

H(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

outputA xor B

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

This is exactly what we need for our hash-based commitments

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

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 signatureCommit

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

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 ShiThe 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.

Possible solution

use a trusted third party.(for example: a judge)

in case of disagreement

Problem

They cannot go to a judge with such a contract!

IdeaMaybe 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 BTCif Bob provides

a proof that Carol is murdered during the

next hourAlice

Question: what if Bob is just lucky and Carol was murdered by someone else?

Solution: add some details

1,000 BTCif Bob provides

a proof that Carol is murdered during the next hour using a .44 Remington Magnum

AliceBob

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

AliceBob

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…

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

Internet