Published on: 2019-12-16T20:12:12+00:00
In a discussion on the Lightning-dev mailing list, concerns were raised about possible stealth attacks on the Bitcoin network that would be difficult to detect until it was too late to react. However, David A. Harding argued that these attacks could be detected by comparing the time of the latest block header to real time. He explained the difference between the normal and pathological cases when Alice requests blocks from honest nodes versus an eclipse attacker. An emergency action should be taken if the difference is too large. Harding also discussed the combination of commitment/penalty transaction censorship with plausible block delays as a possible optimal attack strategy. This strategy maximizes the chance of stealing funds without triggering an alarm. However, there is a case where miners could deliberately trigger a false positive of block delay protection by manipulating Median Time Past (MTP). This problem is partly mitigated by miners keeping MTP far in the past being unable to claim fees from recent time locked transactions.Antoine Riard expressed concern that if executed properly, attacks could stay stealth until it's too late to react. Dave responded that the attacks described are pretty easy to detect by comparing the time of the latest block header to real-time, and emergency action should be taken if the difference is too large. He further explained how this strategy applies to normal and pathological cases. Dave suggested that a possibly optimal attack strategy would be to combine commitment/penalty transaction censorship with plausible block delays, which can maximize an attacker's chance of stealing funds without triggering an alarm.The discussion also focused on the effectiveness of raising alarms in case the best-block nTime field is too far behind. Alarms should be off during Initial Block Download (IBD) to avoid false positives. The validation software needs to remember that it's out of IBD to avoid being pinned back in the past. The usefulness of this countermeasure depends on the assumption that the Bitcoin full node used is differently eclipsable from the Lightning node used. It is suggested that connections should be opened to well-known Lightning Network pubkeys to enhance connectivity and detect tampering.The discussion also touched on Time-Dilation Attacks on Offchain Protocols. The advantage of these attacks over eclipse attacks was questioned, but the details about time-dilation attacks and their workings are not provided in the given context.In another communication, the author advises Lightning node operators to have multiple, redundant, trusted methods of receiving Bitcoin block data in a timely fashion. Delivering header data over the Lightning Network wire protocol may be useful if the Bitcoin fullnode used is differently accessible from the Lightning node used. The author discusses LN error messages triggered at an abnormal rate and background probing of payments that will definitely fail. There is also a scenario where Alice is a victim of an eclipse attack and is only connected to nodes controlled by Mallory, allowing Mallory to sidestep certain protections.The Lightning Network is vulnerable to Eclipse attacks, which can result in theft of funds. Countermeasures have been implemented, but research is needed to ascertain their effectiveness. It is crucial for Lightning node authors and operators to have multiple, redundant, trusted methods of receiving Bitcoin block data in a timely fashion. The article discusses two scenarios of Eclipse attacks on the base layer of Lightning, targeting the CSV security delay and per-hop CLTV-delta, respectively. While funds may not be at risk presently, there remains a need for further research and development in this area.
Updated on: 2023-07-31T22:26:51.532213+00:00