Instructor: Daniele Venturi (Slides from a series of lectures by Stefan Dziembowski)

Transcription

1 Data Privacy and Security Instructor: Daniele Venturi (Slides from a series of lectures by Stefan Dziembowski) Master Degree in Data Science Sapienza University of Rome Academic Year

2 Part VII: 2

3 Specifying Conditions in Bitcoin Strange Transactions: A boolean function P 2 T 2 = T 1 1 BTC Condition C 2 to spend T 2 Witness W 2 [T 3 ] P 3 T 3 = T 2 1 BTC Condition C 3 to spend T 2 Witness W 3 T 3 redeems T 2 if C 2 outputs true upon ([T 3 ], W 3 ) Standard transactions: C 2 T 3, W 3 = V(pk 2, [T 3 ], W 3 ) 3

4 Example A previous transaction that can be spent by Alice T 2 = T 1 1 BTC Condition C T, p, q, σ = 1 iff p, q > 1 and p q = 2501 and σ is Bob s signature on [T] Alice s signature T 3 = T 2 1 BTC Can be spent using Bob s signature p = 41 and q = 61 and Bob s signature on [T 3 ] 4

5 How to do this? The conditions are specified using Bitcoin s scripting language Non-Turing complete (as we want transactions to be verified quickly Stack based OP_DUP OP_HASH cdf64739gt5es9sdfq13apeoir984de4r4o OP_EQUALVERIFY OP_CHECKSIG 5

6 Bitcoin Contracts The strange transactions can be used to create so-called Bitcoin contracts Examples Payment channels Pay money to whoever knows some password Assurance contracts Put a deposit to prove you are not a spammer Pay money only if some event happens Decentralized organizations (avoid lawyers) 6

7 Micropayments Hard to make micropayments in Bitocoin I.e., payments worth a fraction of a cent E.g., for wifi connection or for downloading data Reasons: Non-negligible transactions fees Long transaction confirmation time Inherent limitation (7 trans/sec) Can be solved via so-called payment channels E.g., the Lightning Network 7

8 Application to Secure Computation 8

9 MPC Protocols Protocols where the players do not trust each other Yet they want to achieve a common goal Typically, expressed as a function on the parties secret inputs I don t trust Bob Common goal achieved I don t trust Alice 9

10 Example: Coin Tossing I don t trust Bob Y Y I don t trust Alice Y = 0 with probability 1/2 1 with probability 1/2 10

11 Example: Secure Dating A = 1 if Alice loves Bob 0 otherwise B = 1 if Bob loves Alice 0 otherwise Y Y Y = A AND B 11

12 Example: Secure Dating A set A Alice s friends Bob s friends A set B Y Y = A B (or Y = A B) Y 12

13 Possible Applications Cloud computing Online auctions Electronic voting But do such protocols exist? 13

14 Ideal and Real World Trivial assuming a trusted third party Ideal World A Y Y B Real World A B 14

15 Every Function can be Computed Securely! Manuel Blum Andrew Yao Silvio Micali Oded Goldreich Avi Widgerson Every trusted party can be simulated in a secure manner (under some assumptions) 15

16 The Limitations Lack of fairness when there is no honest majority (see following slides) Partial remedies exist No way to force parties to use true inputs and to respect the outcome Beyond the scope of crypto Andrychowicz, Dziembowski, Malinowski, Mazurek: We can deal with these problems using Bitcoin! 16

17 How to Realize Coin Tossing? A B Y = A xor B Y = A xor B But the bits should be sent at the same time Otherwise parties can easily cheat Seems hard to realize this in the internet 17

18 Solution Using Bit Commitments A Commits to A B B Y = A xor B Opens A Y = A xor B Commitment satisfies two properties Binding: Alice cannot commit to A and later open the commitment to A A Hiding: The commitment hides A 18

19 Hash-Based Commitments Hash function H (modeled as random oracle) In practice, could be SHA-256 To commit to A {0,1}, pick random R {0,1} k and output H(A R) To open A, send (A, R) 19

20 Problem 1 A Commits to A B Opens A B Lack of fairness Alice can refuse to open the commitment Inherent issue in most of the interesting MPC protocols 20

21 Problem 2 You lost! A Commits to A B Opens A B So what?! This is the problem of forcing the parties to respect the output Inherent even in the ideal world specification 21

22 Main Idea Commits to bit A Commits to A If Alice didn t redeem «commit», then Bob can do it after one day B Transaction «commit»: Has value 1 BTC Can be redeemed by Alice Claiming the transaction requires revealing A 22

23 How to do it? Using the Bitcoin scripting language Hash-locked transactions Let H be a hash function and Y = H(X) A Y-hash-locked transaction can be redeemed only by publishing X (in our case X = (A, R)) T 2 = T 1 1 BTC Can be spent using Bob s signature and X such that Y = H(X) Alice s signature 23

24 Alice s Commitment Earlier transaction of Alice "commit" = T 1 BTC Can be spent using Alice s signature and (A, R) such that Y = H(X) Alice s signature Posted on the blockchakin Send to Bob a «refund» transaction "refund" = "commit" 1 BTC Can be spent using Bob s signature after one day Alice s signature 24

25 Solving the Fairness Issue A Commits to A with a Bitcoin-based commitment B Y = A xor B B Opens A Y = A xor B If Alice does not open the commitment within one day, Bob can get 1BTC by posting the «refund» transaction Otherwise Alice gets her 1 BTC back 25

26 Respecting the Output A Commits to A with a Bitcoin-based commitment B Commits to B with a Bitcoin-based commitment A transaction that takes the opening of both commitments and decides who won prob. 1/2 26

27 Final Result Any two-party stateless functionality can be simulated in this way The simulation enforces the financial consequences Generalization to multi-party reactive functionalities by Kumaresan, Moran, Bentov Example: Selling secret information Set union plus a money transfer between Alice and Bob for each new element that they learned 27

28 How to Order a Murder? Carol I want Alice murdered So do it, and I will pay you I can do it for $ Bob No, kill first No, pay first 28

29 A Bad Solution Idea: What if we use some smart technology? 29

30 Murder Contract 1000 BTC if Bob provides a proof that Alice is killed within the next hour E.g., a signed article from some press agency or an authenticated data feed Maybe Bob just gets lucky. So add more details, like «using a.44 Magnum Remington gun.» 30

31 Two Technical Problems Such conditions are impossible to express using Bitcoin syntax A separate contract is needed for every potential hitman Solution: Use Ethereum A currency designed for doing contracts Contracts can be posted on the blockchain and give money to anyone who provides a solution Allows to create arbitrarily complicated contracts. 31

32 Ethereum 32

33 Promises of Ethereum The world computer Build decentralized applications (DAPPs) Trustless & secure smart contracts 33

34 Problems with Bitcoin Too slow Not very usable scripting language Only supports transactions Flexible fees Difficulty adjusted every 1000 blocks Mining centralized and uninteresting 40 blocks/ 10 minutes Turing complete language Accounts & Contracts Computations are payed for in gas Adjusted in every block POW is memory hard 34

35 Ethereum: Some History January 2014 Vitalik Buterin announces Ethereum July 2014 Ethereum Presale (18 Mio $) July 2015 First Release: Frontier March 2016 Second Release: Homestead April 2016 Launch of the DAO July 2016 First Hard Fork May 2016 DAO collects 160 Mio $ June 2016 DAO gets hacked DAO: Decentralized Autonomous Organization

36 A Commitment Contract in Ethereum contract Commitment{ bytes32 commitment; uint timeout; address owner; function commit(bytes32 c) payable { hash = h; timeout = now + 10 minutes; owner = msg.sender; } function open (uint d) { if (sha3(d) == commitment) selfdestruct(msg.sender); } function refund (){ if (timeout < now) self-destruct(owner); } } 1. Challenger deposits coins 2. Solver opens commitment 3. Refund coins

37 Ethereum Virtual Machine (EVM) Contracts are written in higher level languages Solidity(Javascipt) Serpent (Python) LLL (Lisp) EVM: Low-level, stack-based bytecode language Run by every Ethereum node Contracts need to be compiled before deployment Turing complete EVM: Ethereum Virtual Machine LLL : Lisp Like Language

38 Gas Users/contracts can run arbitrary EVM code Every EVM operation has a certain cost (gas) OP Code Gas Description 0x01 ADD 3 Add two values 0x06 MOD 5 Modulo Operation 0x20 SHA3 30 Calculate Keccak-256 of a value 0xf0 CREATE 40 Create a new EOA/ contract address If execution requires more gas than the user sent, all changes are reverted but fee goes to the miner The gas price is determined by free market EVM: Ethereum Virtual Machine

39 Accounts Basic building block of the Ethereum blockchain An account can either be externally owned (EOA) or a contract account Address (20 Bytes) Address (20 Bytes) Nonce Balance Nonce Balance Code Storage

40 State Additionally to the blockchain Ethereum has a concept of state Account Ether Data Account Ether Data Account Ether Data Alice 10 commit Alice 8 open Alice Contract 2 0x x1ac3 0 0x Bob 2 State can be computed from the blockchain Transactions change the state

41 Ethereum Blockchain Block creation in Ethereum is approx. 15 sec Problem: Orphan blocks An orphan, or stale block: Happens when 2 blocks found at the same time In Bitcoin: Only one block is accepted into the blockchain In Ethereum: Orphans can be included in the blockchain as UNCLES Ethereum uses a modification of GHOST protocol GHOST: Greedy Heaviest Observed Subtree 41

42 GHOST Protocol Goal: Neutralize network lag/ centralization A miner gets 12.5% of block reward for every orphan Uncldes cannot be older than 7 blocks Max. 2 uncles allowed per block B 1 B 0 B 1 B 3 B 4 B 2 GHOST: Greedy Heaviest Observed Subtree 42

43 CPU Time Ethash Ethereum's Pow Algorithm (Ethash) is believed to be memory hard Generate a Directed Acylic Graph every blocks (approx. 5.2 days) Needs to be precomputed Computing PoW requires lookups in the DAG Not needed for verification Tradeoff between CPU Speed and Memory Memory

44 Comparison with Bitcoin Language Script vs EVM Data Blockchain vs blockchain + state Unspent transactions vs accounts Unit Bitcoin vs Ether Transaction fees vs gas