FAKULTÄT FÜR!NFORMATIK
Faculty of Informatics

S&P
Security, Privacy andInteroperability in PaymentChannel Networks
Pedro Moreno-Sanchez (@pedrorechez)
Joint work withGiulio Malavolta, Clara Schneidewind,Aniket Kate, Matteo Maﬀei@aniketpkate @matteo_maﬀei

SECURITY &PRIVACYGROUP

Permissionless Blockchains Scalability Issue‣ Low transaction rate (~10 transactions per second)‣ Fast growth of the Bitcoin transactions‣ Scalability approaches:• On-chain (layer 1) sharding• Off-chain (layer 2) payment channels [The focus ofour work]

S&P2Payment Channels

Alice

S&P

Bob

3

Payment Channels: OpenBob

Alice

Blockchain(Alice, Bob): 5
Alice: 5
ALICE

S&P

Alice: 54

Payment Channels: Pay
Alice: 4(Alice, Bob): 5
ALICE

Alice?? BOB

Bob: 1
Bob

Blockchain(Alice, Bob): 5
Alice: 5
ALICE

S&P

Alice: 5
5

Payment Channels: Pay
Alice: 3(Alice, Bob): 5
ALICE

Alice?? BOB

Bob: 2
Bob

Blockchain(Alice, Bob): 5
Alice: 5
ALICE

S&P

Alice: 5
6

Payment Channels: Close

Bob

Alice

Blockchain(Alice, Bob): 5
Alice: 5
ALICE

Alice: 5

Alice: 3(Alice, Bob): 5ALICE

Bob: 2BOB

S&P

7Payment-Channel Networks (PCN)‣ Each payment channel requires to lock coins in thedeposit• Impractical to open a channel with each other‣ Open a few channels• Rely on other channels to reach the intended
receiverS&P

8Payment-Channel Networks (PCN)‣ Each payment channel requires to lock coins in thedeposit• Impractical to open a channel with each other‣ Open a few channels• Rely on other channels to reach the intended
receiver1 BTC to Bob

AliceS&P

1 BTC to Bob

BobCat9

Current PCN (Proposals)‣ Bitcoin and Altcoins:• Lightning network, c-lighntning, Eclair‣ Ethereum:• Raiden Network‣ Eventually, every blockchain might need a scalability
solution

S&P

10What is our group’s research about in PCN?

Our Research‣ Formally describe notions of interest for PCNs in theUniversal Composability framework:• Security, privacy, concurrency‣ Analyze whether current PCNs achieve them
• e.g., we showed an inherent tradeoff privacy vsconcurrency‣ Provide cryptographic constructions with formal
security and privacy guarantees

S&P

12

Security in PCNs

Security Notion‣ Balance security: Honest users do not lose coins in a
multi-hop payment△ = 10

AliceCatBob

Pr < negl△ < 10AliceS&PBobCat
14

Security and HTLC‣ Balance security: Honest users do not lose coins in apayment‣ Security tool: Hash-Time Lock Contract (HTLC):
Payment conditioned on revealing the pre-image of ahash function

S&P

15

Security and HTLC‣ Balance security: Honest users do not lose coins in apayment‣ Security tool: Hash-Time Lock Contract (HTLC):
Payment conditioned on revealing the pre-image of ahash function

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

Alice: 4(Alice, Bob): 5
ALICE

Alice

S&P

Bob?? BOB

Bob: 1y = H(??)
16

The Lightning Network: Setup‣ Multiple “chained’’ HTLC allow multi-hop payments inthe presence of malicious intermediaries

x : H(x) = y

AliceBob

CatyS&P

17

The Lightning Network: Lock
‣ Multiple “chained’’ HTLC allow multi-hop payments inthe presence of malicious intermediaries

HTLC(Alice, Bob, 1.1, y, t) HTLC(Bob, Cat, 1, y, t’)

Alice

S&PBobCat18

The Lightning Network: Lock
‣ Multiple “chained’’ HTLC allow multi-hop payments inthe presence of malicious intermediaries

HTLC(Alice, Bob, 1.1, y, t) HTLC(Bob, Cat, 1, y, t’)AliceBob

CatTransaction feeS&P

19

The Lightning Network: Release‣ Multiple “chained’’ HTLC allow multi-hop payments inthe presence of malicious intermediaries
X

Alice

S&P

X

Bob

Cat20

A Novel Wormhole Attack‣ Idea: Exclude intermediate honest users fromsuccessful completion.
‣ Consequence: Adversary steals fees from honest
users.
HTLC(Adv, Bob, 1.2, y, t2)
HTLC(Adv, Cat, 1, y, t4)
HTLC(Alice, Adv, 1.3, y, t1)

HTLC(Bob, Adv, 1.1, y, t3)

AliceBob

S&P

Adversary

AdversaryCat21

A Novel Wormhole Attack‣ Idea: Exclude intermediate honest users fromsuccessful completion.
‣ Consequence: Adversary steals fees from honest
users.
HTLC(Adv, Bob, 1.2, y, t2)
HTLC(Adv, Cat, 1, y, t4)
HTLC(Alice, Adv, 1.3, y, t1)

HTLC(Bob, Adv, 1.1, y, t3)

AliceBob

Adversary

Adversary

CatX

S&P22

A Novel Wormhole Attack‣ Idea: Exclude intermediate honest users fromsuccessful completion.
‣ Consequence: Adversary steals fees from honest
users.
HTLC(Adv, Bob, 1.2, y, t2)
HTLC(Adv, Cat, 1, y, t4)
HTLC(Alice, Adv, 1.3, y, t1)

HTLC(Bob, Adv, 1.1, y, t3)

Alice

Bob

Adversary

Adversary“Payment Failed”
X

S&P

Cat
X23

A Novel Wormhole Attack‣ Idea: Exclude intermediate honest users fromsuccessful completion.
‣ Consequence: Adversary steals fees from honest
users.
HTLC(Adv, Bob, 1.2, y, t2)
HTLC(Adv, Cat, 1, y, t4)
HTLC(Alice, Adv, 1.3, y, t1)

HTLC(Bob, Adv, 1.1, y, t3)

Alice

Bob

Adversary

Adversary“Payment Failed”
XCatX

Adversary gains 0.3 coins (0.2 fees + Bob’s fee)

S&P

24

The Wormhole Attack: Discussion‣ Same condition along the path enables this attack‣ More intermediaries, more benefit‣ Fees are the base of PCNs. Thus, attack on fees isimportant‣ Intermediary (Bob) believes payment is unsuccessful
HTLC(Adv, Bob, 1.2, y, t2)
HTLC(Adv, Cat, 1, y, t4)
HTLC(Alice, Adv, 1.3, y, t1)
HTLC(Bob, Adv, 1.1, y, t3)

Alice

Adversary
X

S&P

Bob

Adversary“Payment Failed”

CatX
25

What about privacy?

Privacy Notion‣ Relationship Anonymity: The adversary cannot tell
who is paying to whom

Cat

AliceBobCat

Alicepays topays toS&P≈

pays topays to27

Privacy in PCNs
‣ Relationship Anonymity: The adversary cannot tell
who is paying to whom

HTLC(Alice, Adv, 1.3, y)

HTLC(Adv, Cat, 1, y)
HTLC(Adv, Bob, 1.2, y)

HTLC(Bob, Adv, 1.1, y)

Cat

Alice
Bob

Alice’Cat’HTLC(Adv, Bob, 1.2, y’)HTLC(Alice, Adv, 1.3, y’)HTLC(Bob, Adv, 1.1, y’)HTLC(Adv, Cat, 1, y’)Problem: The same condition is used in the complete path!

S&P

28

Other Practical Considerations‣ Scalability issues:• Two keys to define the deposit• Payment condition + signatures required‣ Privacy issues:• Users sharing a channel revealed‣ Interoperability• Support for specific hash function required
Alice: 4(Alice, Bob): 5
ALICE?? BOB

S&P

Bob: 1y = H(??)
29

Summary Current PCN

Current PCN

Security

Wormhole Attack

PrivacyWho pays to whom

Interoperability /Compatibility

Specific hash function

Reduced Tx Size

S&P

Two keys; HTLC script30

What can we do with the signatures?

2-party ECDSA Signing [Lindell17](pkA, skA)
Alice(pkB, skB)
Bob‣ Jointly compute a signature σ on a transaction‣ It requires the knowledge of both skA and skB‣ It can be publicly verified using PKAB := (skA * skB) * G

S&P

32

ECDSA: 2-party channel
Current

SS-ECDSAOpen Channel
pkA: 5ALICE(pkA, pkB): 5
pkA: 5

pkA: 5ALICE

pkAB: 5pkA: 5

Oﬀ-chain Payment(pkA, pkB): 5
ALICE

S&P

pkA: 3pkB: 2pkAB: 5ALICE

pkA: 3pkB: 233

What if we encode the conditions in thesignatures themselves?

Scriptless Scripts (Schnorr)‣ Original idea proposed by Andrew Poelstra‣ “Encode” payment condition within the Schnorrsignatures‣ In our work: formal description and analysis‣ Unfortunately, Schnorr is not used in many
cryptocurrencies today

S&P

35

Scriptless Scripts (SS-ECDSA)‣ Was an open problem before our work
‣ Main challenge is the signature structure: No longer alinear combination• Schnorr signature: (r1 + r2) + (k1 + k2) m• ECDSA signature: (r-1 * r-2) Rx (k1 * k2) + (r-1 * r-2) m− Requires inverse, x coordinate of an elliptic
curve point and multiplicative shares of the key
k = k1 * k2
‣ In our work: formal description and analysis

S&P36

2-party ECDSA Conditional Signing
Condition: (pkC)(pkA, skA)
Alice

(pkB, skB)
BobGoals:‣ Alice can create a “half-signature” that Bob can finish
only with skC‣ If Bob creates a signature, Alice learns skC

S&P37

2-party ECDSA Conditional Signing(pkA, skA)

Condition: (pkC)(pkB, skB)

AliceBob

Create pkAB and combine randomness R := (pkC, rA, rB)
Send “1/3-signature” σB
Send “1/3-signature” σA
Send whole signature: σ := σA * σB * σCCompute σC := σ * (σB)-1 * (σC)-1Retrieve skC from σC

S&P

Learn skC38

2-party ECDSA Conditional Signing(pkA, skA)

Condition: (pkC)(pkB, skB)

Alice

Bob

LOCK

Create pkAB and combine randomness R := (pkC, rA, rB)
Send “1/3-signature” σB
Send “1/3-signature” σASend whole signature: σ := σA * σB * σCCompute σC := σ * (σB)-1 * (σC)-1Retrieve skC from σC

S&P

Learn skCRELEASE39

ECDSA-based PCN: Setup‣ Multiple “chained’’ ECDSA conditional payments allow
multi-hop payments in the presence of malicious
intermediaries(skD, pkD := skD * G)
(skE, pkE := skE * G)
pkDE := pkD + pkE
pkD, pkDE,skE

Alice

S&PBobCat40ECDSA-based PCN: Setup‣ Multiple “chained’’ ECDSA conditional payments allow
multi-hop payments in the presence of malicious
intermediaries(skD, pkD := skD * G)
(skE, pkE := skE * G)
pkDE := pkD + pkE
pkDE, skDE
pkD, pkDE,skE

Alice

S&P

BobCat41

ECDSA-based PCN: Lock‣ Multiple “chained’’ ECDSA conditional payments allow
multi-hop payments in the presence of malicious
intermediaries

LOCK(Alice, Bob, 1.1, pkD, t)

Alice

S&P

LOCK(Bob, Cat, 1, pkDE, t’)

BobCatskE

skDE42ECDSA-based PCN: Lock‣ Multiple “chained’’ ECDSA conditional payments allow
multi-hop payments in the presence of malicious
intermediaries

LOCK(Alice, Bob, 1.1, pkD, t)

Alice

LOCK(Bob, Cat, 1, pkDE, t’)

BobCatskE

skDE

Randomized conditions in the path: Security and Privacy

S&P

43

ECDSA-based PCN: Release‣ Multiple “chained’’ ECDSA conditional payments allow
multi-hop payments in the presence of malicious
intermediaries
skD

Alice

S&P

skDE

BobCat

skE

skDE

44

ECDSA-based PCN: Discussion‣ It can be extended to arbitrary number of hops
‣ It reduces transaction size for conditional paymentspkAB: 5ALICE

pkA: 4
pkABC: 1‣ Evaluation: <500 bytes communication. Few mscomputation‣ Improve interoperability. Useful for other applications(e.g., atomic swaps and cross-chain payments)‣ Compatible with Bitcoin

S&P45

Summary Current ECDSA

Current
PCN

ECDSA-based
PCNSecurity

One secret per user

PrivacyRandomized conditions

Interoperabili
ty /Compatibility

Only ECDSA required

Reduced Tx
Size

S&P

Condition in one key46

Summary‣ More in the paper:• One-way homomorphic functions suffice for multi-hop locks in full script setting• Possible to combine OWH-Schnorr-ECDSA locks inthe same path
• Security and privacy modelled and proven in theUniversal Composability Framework —>Composability guarantees‣ Multi-hop locks implemented in the LightningNetwork‣ It enables a plethora of applications (e.g., atomicswaps and cross-chain payments)

S&P47