Concurrency and Privacy with Payment Channel Networks

Transcription

1 Concurrency and Privacy with Payment Channel Networks Giulio Malavolta, Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei*, and Srivatsan Ravi Friedrich-Alexander-University Purdue University *TU Vienna

2 Bitcoin Scalability Issues < 10 transactions per second > 135 GB of memory required No micropayment (high fees) 2

3 Payment Channels Enable multiple payments between two users without committing every single payment to the blockchain Alice Alice Alice Bob Bob Bob 3

4 Payment Channel Networks (PCN) Each payment channel requires to deposit bitcoins Impractical to open a channel with every other user 1 BTC to Bob 1 BTC to Cat Alice Bob Cat 4

5 Hash Time-Lock Contracts Hash-Time Lock Contract (HTLC) enables conditional payments between two users Alice HTLC(Alice, Bob, 1, y, 30): Pay Bob 1 BTC iff Bob shows some x such that H(x) = y, before 30 days Bob (x, ) H(x) = y? 5

6 The Lightning Network Multiple chained HTLC enable multi-hop payments in the presence of untrusted intermediaries x : H(x) = y Alice Bob Cat y 6

7 The Lightning Network Multiple chained HTLC enable multi-hop payments in the presence of untrusted intermediaries HTLC(Alice, Bob, 1, y, 30) Alice x : H(x) = y Bob Cat y 7

8 The Lightning Network Multiple chained HTLC enable multi-hop payments in the presence of untrusted intermediaries HTLC(Bob, Cat, 1, y, 29) HTLC(Alice, Bob, 1, y, 30) Alice Bob x : H(x) = y Cat y 8

9 The Lightning Network Multiple chained HTLC enable multi-hop payments in the presence of untrusted intermediaries HTLC(Bob, Cat, 1, y, 29) HTLC(Alice, Bob, 1, y, 30) Alice x Bob Cat y 9

10 The Lightning Network Multiple chained HTLC enables multi-hop payments in the presence of untrusted intermediaries Bob does not gain or lose coins HTLC(Alice, Bob, 1, y, 30) Alice HTLC(Bob, Cat, 1, y, 29) Bob x Cat y 10

11 Contributions Definition of security and privacy properties for PCNs Privacy analysis of PCNs and solution (Fulgor) Concurrency analysis of PCNs and solution (Rayo) Prototype implementation 11

12 Security Properties Our model highlights two main security properties: Balance Security: Pr [ ] Serializability: => 12

13 Privacy Properties Our model highlights two privacy properties (Off-path) value privacy: (On-path) relationship anonymity: 13

14 Privacy in PCNs: Challenge? Off-chain payments => Privacy-preserving payments HTLC(Alice, Bob, 1, y, 30) Alice HTLC(Bob, Cat, 1, y, 29) Bob Figure 1: Illustrative example of payment channel. White solid boxes denote Bitcoin addresses and their current balance, dashed Cat Figure 2: Illustrative example of (bold) numbers represent the capa the payment from Alice to Bob. A via Carol, Edward and Fabi. 14 There

15 Privacy in PCNs: Challenge? Off-chain payments => Privacy-preserving payments HTLC(Alice, Bob, 1, y, 30) Alice HTLC(Bob, Cat, 1, y, 29) Bob Figure 1: Illustrative example of payment channel. White solid boxes denote Bitcoin addresses and their current balance, dashed Same y! Cat Figure 2: Illustrative example of (bold) numbers represent the capa the payment from Alice to Bob. A via Carol, Edward and Fabi. 15 There

16 Privacy in PCNs: Our Solution Our setting: P2P Network Our goal: On-chain operations: HTLC as in the Lightning Network Rest of cryptographic operations must be off-chain Full compatibility with the current Bitcoin script Our solution: Fulgor: Based on Multi-hop HTLC 16

17 Multi-hop HTLC Building block: Non-interactive zero knowledge (ZKBoo [GMO16]) Alice Bob Cat x 0 : H(x 0 ) = y 0 x 1 : H(x 0 x 1 ) = y 1 17

18 Multi-hop HTLC Building block: Non-interactive zero knowledge (ZKBoo [GMO16])? H(x 0 ) = y 0 Alice Bob Cat x 0 : H(x 0 ) = y 0 x 1 : H(x 0 x 1 ) = y 1 (x 0, y 0 ) 18

19 Multi-hop HTLC Building block: Non-interactive zero knowledge (ZKBoo [GMO16]) V(s,") = 1 Alice x0 : H(x0) = y0 x1 : H(x0 x1) = y1 Bob s := (x1, y1, y0, ") Cat! : x0 s.t. H(x0 x1) = y1 H(x0) = y0 19

20 Multi-hop HTLC Building block: Non-interactive zero knowledge (ZKBoo [GMO16]) HTLC(Alice, Bob, 1, y1, 30) Alice x0 : H(x0) = y0 x1 : H(x0 x1) = y1 Bob Cat s := (x1, y1, y0, ")! : x0 s.t. H(x0 x1) = y1 H(x0) = y0 20

21 Multi-hop HTLC Building block: Non-interactive zero knowledge (ZKBoo [GMO16]) HTLC(Alice, Bob, 1, y1, 30) HTLC(Bob, Cat, 1, y0, 29) Alice x0 : H(x0) = y0 x1 : H(x0 x1) = y1 Bob Cat s := (x1, y1, y0, ")! : x0 s.t. H(x0 x1) = y1 H(x0) = y0 21

22 Multi-hop HTLC HTLC(Alice, Bob, 1, r1, 30) HTLC(Bob, Cat, 1, r0, 29) HTLC(Alice, Bob, 1, y1, 30) HTLC(Bob, Cat, 1, y0, 29) Alice x0 : H(x0) = y0 x1 : H(x0 x1) = y1 Bob Cat s := (x1, y1, y0, ")! : x0 s.t. H(x0 x1) = y1 H(x0) = y0 22

23 Multi-hop HTLC x1 x0 HTLC(Alice, Bob, 1, y1, 30) Alice x0 : H(x0) = y0 x1 : H(x0 x1) = y1 Bob HTLC(Bob, Cat, 1, y0, 29) x0 Cat s := (x1, y1, y0, ")! : x0 s.t. H(x0 x1) = y1 H(x0) = y0 23

24 Multi-hop HTLC Soundness of NIZK => Bob does not loss coins Zero-knowledge of NIZK => Bob does not steal coins x1 x0 HTLC(Alice, Bob, 1, y1, 30) Alice x0 : H(x0) = y0 x1 : H(x0 x1) = y1 Bob HTLC(Bob, Cat, 1, y0, 29) x0 Cat s := (x1, y1, y0, ")! : x0 s.t. H(x0 x1) = y1 H(x0) = y0 24

25 Concurrency in PCNs Concurrent on-chain payments can be easily ordered by miners No user has a complete view of off-chain concurrent payments in a P2P network A blocking solution can lead to deadlocks Alice to Gabriel Bob to Edward 25

26 Concurrency in PCNs Concurrent on-chain payments can be easily ordered by miners No user has a complete view of off-chain concurrent payments in a P2P network A blocking solution can lead to deadlocks Alice to Gabriel Bob to Edward 26

27 Concurrency in PCNs Concurrent on-chain payments can be easily ordered by miners No user has a complete view of off-chain concurrent payments in a P2P network A blocking solution can lead to deadlocks Alice to Gabriel Bob to Edward 27

28 Concurrency in PCNs Concurrent on-chain payments can be easily ordered by miners No user has a complete view of off-chain concurrent payments in a P2P network A blocking solution can lead to deadlocks Alice to Gabriel Bob to Edward 28

29 Concurrency in PCNs: Our Solution A non-blocking solution (Rayo): at least one payment finishes Main idea: Use global transaction identifiers T2 T1 Alice to Gabriel Bob to Edward Queue T2 Abort T1 29

30 Concurrency vs Privacy Tradeoff Global identifiers leak transaction ID to intermediate users Non-blocking solutions cannot achieve strong privacy BLOCKING (Fulgor) Anonymity set for P 0 NON-BLOCKING (Rayo) Anonymity set for P 0 30

31 Implementation and Performance Running time of our solution largely dominated by NIZK Creating a proof requires 309 ms. Proof verification requires 130 ms Proof size: 1.65MB 5-hop payment: Non-private (LN): 609 ms Private: 1929 ms and ~ 5 MB (Proofs are not included in the blockchain) 31

32 Conclusions Define the security and privacy properties of interest in PCN Inherent tradeoff between concurrency and privacy Fulgor and Rayo: two approaches for concurrency and privacy Our solutions are efficient, compatible with Bitcoin script and without storage overhead in the blockchain 32

33 Paper: eprint.iacr.org/2017/820 Thank you for your attention! Giulio Malavolta, Pedro Aniket Kate, Matteo Maffei, and