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

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

2

Payment Channels✤ Enable multiple payments between two users withoutcommitting every single payment to the blockchain

Alice

Alice

Alice

Bob

Bob

Bob3

Payment Channel Networks (PCN)✤ Each payment channel requires to deposit bitcoins✤ Impractical to open a channel with every other user

1 BTC to Bob

Alice

1 BTC to CatBobCat4

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 somex such that H(x) = y, before 30 days

Bob(x ,)

H(x) = y?

5

The Lightning Network✤ Multiple “chained” HTLC enable multi-hop payments inthe presence of untrusted intermediaries

x : H(x) = y

AliceBobCaty6

The Lightning Network✤ Multiple “chained” HTLC enable multi-hop payments inthe presence of untrusted intermediaries

HTLC(Alice, Bob, 1, y, 30)

Alicex : H(x) = yBobCaty7

The Lightning Network✤ Multiple “chained” HTLC enable multi-hop payments inthe presence of untrusted intermediaries

HTLC(Bob, Cat, 1, y, 29)

HTLC(Alice, Bob, 1, y, 30)

AliceBobx : H(x) = y

Caty8

The Lightning Network✤ Multiple “chained” HTLC enable multi-hop payments inthe presence of untrusted intermediaries

HTLC(Bob, Cat, 1, y, 29)

HTLC(Alice, Bob, 1, y, 30)

AlicexBobCaty9The Lightning Network✤ Multiple “chained” HTLC enables multi-hop payments inthe presence of untrusted intermediaries✤ Bob does not gain or lose coins

HTLC(Alice, Bob, 1, y, 30)

Alice

HTLC(Bob, Cat, 1, y, 29)

Bobx

Caty10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

Security Properties✤ Our model highlights two main security properties:✤Balance Security:△ = 10Pr [✤△=9after payment]< negl

Serializability:
2a12b2=>1312

Privacy Properties✤ Our model highlights two privacy properties✤(Off-path) value privacy:
4✤444

≈

2222(On-path) relationship anonymity:
P0
P1P0
P1

P0
P1

P0P1

≈

P0
P1P0
P1

P1
P0

P1P013

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 solidboxes denote Bitcoin addresses and their current balance, dashedCat

Figure 2: Illustrative example of(bold) numbers represent the capa
the payment from Alice to Bob. A
via Carol, Edward and Fabi. 14
There

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

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

Multi-hop HTLC
✤ Building block: Non-interactive zero knowledge (ZKBoo [GMO16])

AliceBobCat

x0 : H(x0) = y0
x1 : H(x0 ⊕ x1) = y117

Multi-hop HTLC
✤ Building block: Non-interactive zero knowledge (ZKBoo [GMO16])?
H(x0) = y0

Alicex0 : H(x0) = y0
x1 : H(x0 ⊕ x1) = y1

BobCat(x0 , y0)18

Multi-hop HTLC
✤ Building block: Non-interactive zero knowledge (ZKBoo [GMO16])

V(s,") = 1

Alicex0 : H(x0) = y0
x1 : H(x0 ⊕ x1) = y1

Bobs := (x1 , y1, y0, ")Cat! : ∃ x0 s.t. H(x0 ⊕ x1) = y1 ∧H(x0) = y0
19

Multi-hop HTLC
✤ Building block: Non-interactive zero knowledge (ZKBoo [GMO16])

HTLC(Alice, Bob, 1, y1, 30)

Alicex0 : H(x0) = y0
x1 : H(x0 ⊕ x1) = y1

BobCats := (x1 , y1, y0, ")! : ∃ x0 s.t. H(x0 ⊕ x1) = y1 ∧H(x0) = y020

Multi-hop HTLC
✤ Building block: Non-interactive zero knowledge (ZKBoo [GMO16])

HTLC(Alice, Bob, 1, y1, 30) HTLC(Bob, Cat, 1, y0, 29)

Alicex0 : H(x0) = y0
x1 : H(x0 ⊕ x1) = y1

BobCats := (x1 , y1, y0, ")! : ∃ x0 s.t. H(x0 ⊕ x1) = y1 ∧H(x0) = y021

Multi-hop HTLCHTLC(Alice, Bob, 1, r1, 30) HTLC(Bob, Cat, 1, r0, 29)≈≈

HTLC(Alice, Bob, 1, y1, 30) HTLC(Bob, Cat, 1, y0, 29)

Alicex0 : H(x0) = y0
x1 : H(x0 ⊕ x1) = y1

Bob

Cats := (x1 , y1, y0, ")! : ∃ x0 s.t. H(x0 ⊕ x1) = y1 ∧H(x0) = y022

Multi-hop HTLC

x1 ⊕ x0
HTLC(Alice, Bob, 1, y1, 30)

Alicex0 : H(x0) = y0x1 : H(x0 ⊕ x1) = y1

Bob

HTLC(Bob, Cat, 1, y0, 29)x0Cats := (x1 , y1, y0, ")! : ∃ x0 s.t. H(x0 ⊕ x1) = y1 ∧H(x0) = y023

Multi-hop HTLC
✤ Soundness of NIZK => Bob does not loss coins✤ Zero-knowledge of NIZK => Bob does not steal coinsx1 ⊕ x0
HTLC(Alice, Bob, 1, y1, 30)

Alicex0 : 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) = y024

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 Edward25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 Edward26

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 Edward27

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 Edward28Concurrency in PCNs: Our Solution✤ A non-blocking solution (Rayo): at least one payment finishes✤ Main idea: Use global transaction identifiers

T2
T1Alice to Gabriel
Bob to Edward

Queue T2

Abort T129

Concurrency vs Privacy Tradeoff✤ Global identifiers leak transaction ID to intermediate users

NON-BLOCKING BLOCKING(Rayo)(Fulgor)✤ Non-blocking solutions cannot achieve strong privacy

P0

P0
P1

P*0
P*1

P*0Anonymity set for P0

P1

P*1

P0

P0

P1

P0
P1P0
P1Anonymity set for P0
P130

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

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 andwithout storage overhead in the blockchain

32

Paper: eprint.iacr.org/2017/820

Thank you for your attention!
Giulio Malavolta, Pedro Moreno-Sanchez,@pedrorechez

Aniket Kate, Matteo Maffei, and Srivatsan Ravi@aniketpkate@matteo_maffei