Hijacking Routes in Payment Channel Networks: A Predictability Tradeoff
September 15, 2019 Β· Declared Dead Β· π arXiv.org
"No code URL or promise found in abstract"
Evidence collected by the PWNC Scanner
Authors
Saar Tochner, Stefan Schmid, Aviv Zohar
arXiv ID
1909.06890
Category
cs.CR: Cryptography & Security
Cross-listed
cs.GT,
cs.MA,
cs.NI
Citations
56
Venue
arXiv.org
Last Checked
5 months ago
Abstract
Off-chain transaction networks can mitigate the scalability issues of today's trustless electronic cash systems such as Bitcoin. However, these peer-to-peer networks also introduce a new attack surface which is not well-understood today. This paper identifies and analyzes, a novel Denial-of-Service attack which is based on route hijacking, i.e., which exploits the way transactions are routed and executed along the created channels of the network. This attack is conceptually interesting as even a limited attacker that manipulates the topology through the creation of new channels can navigate tradeoffs related to the way it attacks the network. Furthermore, the attack also highlights a fundamental design tradeoff for the defender (who determines its own routes): to become less predictable and hence secure, a rational node has to pay higher fees to nodes that forward its payments. We find that the three most common implementations for payment channels in Bitcoin (lnd, C-lightning, Eclair) approach routing differently. We begin by surveying the current state of the Lightning network and explore the routes chosen by these implementations. We find that in the current network nearly 60\% of all routes pass through only five nodes, while 80\% go through only 10 nodes. Thus, a relatively small number of colluding nodes can deny service to a large fraction of the network. We then turn to study an external attacker who creates links to the network and draws more routes through its nodes by asking for lower fees. We find that just five new links are enough to draw the majority (65\% - 75\%) of the traffic regardless of the implementation being used. The cost of creating these links is very low. We discuss the differences between implementations and eventually derive our own suggested routing policy, which is based on a novel combination of existing approaches.
Community Contributions
Found the code? Know the venue? Think something is wrong? Let us know!
π Similar Papers
In the same crypt β Cryptography & Security
R.I.P.
π»
Ghosted
R.I.P.
π»
Ghosted
The Limitations of Deep Learning in Adversarial Settings
R.I.P.
π»
Ghosted
Distillation as a Defense to Adversarial Perturbations against Deep Neural Networks
R.I.P.
π»
Ghosted
Spectre Attacks: Exploiting Speculative Execution
R.I.P.
π»
Ghosted
How To Backdoor Federated Learning
R.I.P.
π»
Ghosted
Evasion Attacks against Machine Learning at Test Time
Died the same way β π» Ghosted
R.I.P.
π»
Ghosted
Federated Learning: Strategies for Improving Communication Efficiency
R.I.P.
π»
Ghosted
In-Datacenter Performance Analysis of a Tensor Processing Unit
R.I.P.
π»
Ghosted
Deep Convolutional Neural Networks for Computer-Aided Detection: CNN Architectures, Dataset Characteristics and Transfer Learning
R.I.P.
π»
Ghosted