Robustness of Lightning Network in...
Transcript of Robustness of Lightning Network in...
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: [email protected]
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?