Robustness of Lightning Network in Bitcoin

Hyoungshick KimSungkyunkwan University, CSIRO Data61

for IoT

About me• Associate Professor in Department of Software, Sungkyunkwan University

• Visiting Researcher in CSIRO, Data61 (at Marsfield, Australia)

• Education

✓ Ph.D. in Computer Science, University of Cambridge

• Experiences

✓ Professor, Sungkyunkwan University, Korea (2013 – present)

✓ Postdoctoral Fellow, University of British Columbia, Canada (2012-2013)

✓ Senior Engineer, Samsung Electronics, Korea (2004-2008)

• Research interests:

✓ Usable security

✓ Blockchain

✓ Data-driven security solution design

✓ Security vulnerability analysis

• Homepage: http://seclab.skku.edu/

• Email: hyoung@skku.edu

Why is Bitcoin so slow?

A winner node should be chosen among 15,000 nodes in a fair manner every time

Scalability of Bitcoin

• Scaling limitations

– 1 block = 1 MB max

– 1 block ~ 2000 txns

– 1 block ~ 10 min

– So, 3-4 txns / sec

• VISA peak load comparison

– Typically 2,000 txns / sec

– Peak load in 2013: 47,000 txns / sec

Micropayment don’t actually work

There’s no easy fix

• Increasing block size improves throughput

– Result: Bigger blocks take longer to propagate in the network

• Reducing the block interval reduces latency

– Result: leads to instability where the system is in disagreement

• Designing secure and efficient consensus protocols

• Introducing the second layer protocol (i.e., Lightning Network)

Payment channels

Payment channel (1)• Take small transactions out of the main blockchain (off chain)

• Suppose Bob buys a coffee regularly at Starbucks

• It is inefficient to use the main blockchain for small transactions

• The solution is to set up a multi-signature address that is shared by Bob and Starbucks

Multi-signature address

Bob deposits 0.05BTC Starbucks deposits 0.00BTC

Multi-signature address is like a vault that can only be opened when both parties agree. This is a “payment channel”.

Payment Channel Ledger

Bob 0.05

Starbucks 0.00

Payment channel (2)

Multi-signature address

Bob deposits 0.05BTC Starbucks deposits 0.00BTCPayment Channel Ledger

Bob 0.05

Starbucks 0.00

IF

<expiry time> CHECKLOCKTIMEVERIFY DROP

<Bob's pubkey> CHECKSIGVERIFY

1

ELSE

2

ENDIF

<Bob's pubkey> <Starbuck's pubkey> 2 CHECKMULTISIG

scriptPubKeys value: 0.05

Payment channel (3)

• Bob goes to Starbucks and orders an expresso which costs 0.005 BTC

• Payment channel ledger is updated off chain

• Starbucks signs the updated balance sheet and keeps a copy of the ledger

• There is no limit on the number of transactions per second because these transactions are happening off chain

Payment Channel Ledger

Bob 0.05

Starbucks 0.00

Payment channel (4)

0 <Bob’s signature> <Starbucks’ signature>

scriptSig

IF

<expiry time> CHECKLOCKTIMEVERIFY DROP

<Bob's pubkey> CHECKSIGVERIFY

1

ELSE

2

ENDIF

<Bob's pubkey> <Starbucks' pubkey> 2 CHECKMULTISIG

scriptPubKeys

Input Output Input Output

value: 0.05

Previous transaction Next transaction

Payment channel (5)

Multi-signature address

Bob bought a coffeePayment Channel Ledger

Bob 0.045

Starbucks 0.005

<Bob's pubkey> CHECKSIG

scriptPubKeys

value 0.045

<Starbucks’ public key> CHECKSIG

scriptPubKeys

value 0.005

Payment channel (6)

Multi-signature address

Payment Channel Ledger

Bob 0.04

Starbucks 0.01

<Bob's pubkey> CHECKSIG

scriptPubKeys

value 0.04

<Starbucks’ public key> CHECKSIG

scriptPubKeys

value 0.01

Bob bought a coffee

Payment channel (7)

Multi-signature address

Payment Channel Ledger

Bob 0.035

Starbucks 0.015

<Bob's pubkey> CHECKSIG

scriptPubKeys

value 0.035

<Starbucks’ public key> CHECKSIG

scriptPubKeys

value 0.015

Bob bought a coffee

Payment channel (8)• Payment channel can be closed at any time• Either party simply needs to take the latest ledger which is signed by both

parties and broadcasts it to the network• Miners verify the signatures on the ledger and then release the funds (single

transaction to close). This is an on-chain transaction

0.035 to Bob

0.015 to SB

Payment Channel Ledger

Bob 0.05

Starbucks 0.00

<Bob's pubkey> CHECKSIG

scriptPubKeys

value 0.035

<Starbucks’ public key> CHECKSIG

scriptPubKeys

value 0.015

Applications

• Micropayments

– Sending satoshis with small transaction fees

• Payment streaming

– Sending small amount of money frequently

– E.g., pay per second when watching video on YouTube

• Machine-to-Machine payments

– Bandwidth, data, storage, CPU time, data can be traded

– API endpoints usages

Can we combine payment channels?

Alice Bob

Bob Carol

Open payment channel

Open payment channel

Alice BobPayment channel

CarolPayment channel

1. Alice wants to send 1 BTC to Carol via Bob

2. Alice pays 1 BTC to Bob, Bob pays 1 BTC to Carol

Things that may go wrong here …

- Alice does not trust Bob or Carol

- Alice can pay Bob, Bob can choose not to pay Carol

- Bob can pay Carol, but Carol can claim that she did not receive the

funds

Can we combine payment channels?

Alice wants to send 1 BTC to Carol via

Bob

1. Carol needs to create an invoice

consists of Vrand & H(Vrand);

Carol sends H(Vrand) to Alice;

Alice tells Carol to receive 1 BTC

from Bob

2. Alice tells Bob that she will pay

him 1 BTC if he can produce

H(Vrand); Bob needs Vrand

3. Bob gives 1 BTC to Carol;

Carol gives Vrand to Bob

4. Bob gives Vrand to Alice as a proof;

Alice gives 1 BTC to Bob

We can achieve decentralized, instant, off-

chain transfer of Bitcoin without Trust

Lightning Network

Network finds the fastest and cheapest way to connect A to B. It is also important that the channels have enough funds to do the transaction

A

B

• Actual payments were used through payment channels

• August 9, 2019: 4,438 nodes and 31,489 channels

https://explorer.acinq.co/

Lightning Network mainnet

How reliable is Lighting Network

How about targeted attacks?

Lightning Network includes a small number of highly connected hub nodes that are functionally valuable

Targeted attacks might be much more effective

Attack strategies

• Random removal

– Select nodes to be removed, randomly

• High-degree removal

– Select nodes to be removed, according to their degree

• High-centrality removal

– Select nodes to be removed, according to their betweenness centrality

• Community based removal

– Select nodes to be removed using the community structure of the network

How can we evaluate attacks?

• We use the connectivity of the graph 𝐺 to measure the difficulty of breaking the graph apart.

• The connectivity of 𝐺, written 𝜅(𝐺), is the minimum size of a vertex set 𝑆 such that 𝐺 − 𝑆 is disconnected.

• However, since this metric is based on a worst-case situation, it does not reflect the “global connectedness” of the graph.

• The left graph is clearly connected well compared with the right graph; however, both graphs have connectivity 1.

Average connectivity

• The average connectivity of a graph 𝐺 with 𝑛 vertices, written 𝑘(𝐺), is σ𝑢,𝑣 ∈𝑉(𝐺) 𝑘(𝑢,𝑣)

𝑛2

, where 𝜅(𝑢, 𝑣) is the minimum number of vertices

whose deletion makes 𝑣 unreachable from 𝑢.

𝑘(𝐺) =27

7𝑘(𝐺) =

12

7

We will use “average connectivity” to evaluate the performance of attack and defense strategies

Effectiveness of targeted attack

• Targeted attacks efficiently destroy the lightning network.

Defense strategies

• Random replenishment

– Create a node and add it to the network such that the node is connected to randomly selected different nodes

• Preferential replenishment

– Create a node and add it to the network such that the node is connected to different nodes with probability proportional to their degree

• Balanced replenishment

– Create a node and add it to the network such that the node is connected to different nodes with probability inversely proportional to their betweenness centrality

VS Random node attack

• Balanced defense strategy produced the best results.

VS High-degree node attack

• Balanced defense strategy produced the best results but its effectiveness is limited.

VS High-centrality node attack

• The effectiveness of high-centrality node attack is similar to that of high-degree attack.

VS Community-based attack

• Balanced defense strategy provides better results.

Summary

• Blockchain communities are trying to solve the scalability problem of blockchain

• Payment channel and/or Lightning Network is a possible solution

• However, the current Lightning Network topology is highly centralized, which could be vulnerable to targeted DoS attacks

– Balanced peer assignment is an effective defense strategy

Any questions?