Lightning Network (LN) is a widely-used network of payment channels enabling faster and cheaper Bitcoin transactions. In this paper, we outline three ways an attacker can steal funds from honest LN users. The attacks require dilating the time for victims to become aware of new blocks by eclipsing (isolating) victims from the network and delaying block delivery. While our focus is on the LN, time-dilation attacks may be relevant to any second-layer protocol that relies on a timely reaction.
According to our measurements, it is currently possible to steal the total channel capacity by keeping a node eclipsed for as little as 2 hours. Since trust-minimized Bitcoin light clients currently connect to a very limited number of random nodes, running just 500 Sybil nodes allows an attacker to eclipse 47% of newly deployed light clients (and hence prime them for an attack). As for the victims running a full node, since they are often used by large hubs or service providers, an attacker may justify the higher eclipse attack cost by stealing all their available liquidity.
In addition, time-dilation attacks neither require access to hashrate nor purchasing from a victim. Thus, this class of attacks is a more practical way of stealing funds via eclipse attacks than previously anticipated double-spending.
We argue that simple detection techniques based on the slow block arrival alone are not effective, and implementing more sophisticated detection is not trivial. We suggest that a combination of anti-eclipse/anti-Sybil measures are crucial for mitigating time-dilation attacks.
“The paper presents a number of attacks on the Lightning Network based on the time-dilation attack on the underlying Bitcoin network. The attacks use the ability of an attacker to desynchronize the victim from the rest of the network to break the timing assumptions built into the Lightning Network protocol, such as being able to witness and react to actions that happen on-chain in a timely fashion.”
“The author provides a new way of profiting from eclipse attacks by abusing stale-state closes of Lightning Network channels.”
“Attacker can interfere with the delivery of new blocks (via neutrino) to attack a lightning node.”
“While the attacks themselves have been known about for quite some time, being explicitly mentioned in all off-chain proposals, the paper presents a novel combination of a time-dilation attack and the resulting lag in the lightning protocol. The analysis of the effective parameters for various implementations is well executed, though it appears that they are theoretical in nature, and have not been implemented or performed to validate them.
An important contribution that should not be overlooked are the methods to verify an eclipse attack.”
“Very elaborate and clear articulation of the basics of Lightning Network, how to setup the attack and what are the exact places where LN and Bitcoin nodes are most vulnerable, and three different attacks, all practical”
“Feasible attack. Just need to spawn enough light clients on the network. Time measurements provided for popular implementations (c-lighthning, LND, etc). Good discussion around countermeasures (and how it is pretty difficult to detect dilation attacks).”
“Fundamentally, all three attacks (A1/A2/A3) rely on the same technique. It would be better to provide a general framing for the attack which is to somehow unbalance the channel in favor of the attack and then send a claim transaction on-chain. A1/A2/A3 are variations of the same attack, but just showing how you can exploit the various subtle challenges in lightning.”
“As mentioned above the attacks are not exactly novel, and the time-dilation attack is part of a number of DoS attack vectors that all share the same outcome.”
“Bitcoin Core does not have light client support and it has not implemented BIP157 to the best of my knowledge. It is implied by the time measurements that users of Bitcoin Core are vulnerable to this attack and can be eclipsed on the network. I doubt whether that is true; so I'd recommend [including] an extra few sentences to explain why Bitcoin Core is relevant to Table 2-4.”
“There is no implementation of the attacks. An implementation would allow other researchers to reproduce [the] results and also potentially continue [this] research... Also, it would provide an easy way to validate [the] results. [One implementation may be] running a script which deploys one Bitcoin and one Lightning Network node, connects it to eight malicious peers, and starts illustrating how each attack works one by one.”