Time-dilation Attacks on the Lightning Network



Summary:

The article discusses an attack on the Lightning Network that targets per-hop packet delay. The attacker routes via the victim, who should have at least two channels with the attacker. However, the existence of offchain-to-onchain swap services means that the attacker needs only build one channel to the victim for this attack to work. The incoming channel need not be directly connected to the victim, and the same attack schema works on the onchain side. The article also suggests running a Bitcoin full node on clearnet while running a Lightning node over Tor as a mitigation strategy to prevent eclipsing of Bitcoin nodes. Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) "only" loses you the ability to pay, receive, or route but as long as your blockchain view is clear, it should be fine. This would also prevent any correlation between the Lightning node and the Bitcoin node when transactions are broadcast with the attached Bitcoin node. Furthermore, if a node doesn't observe a block within the last 30 minutes, it attempts to make a new random connection to someone in the network. A mitigation to this would be to run a background process which sleeps for 20 minutes, then does bitcoin-cli addnode ${BITCOINNODE} onetry. However, getting a Bitcoin node that is not part of the eclipsing attacker is essential. Lastly, it is suggested that if a Lightning node is behind in its Bitcoin blockchain view but Lightning payments between honest nodes are still flowing through it, this node would have a high routing failure rate. The victim could instead check that the absolute timelocks seem very far in the future relative to its own view of the current blockheight. A forwarding node might want to do this anyway to have an upper bound against griefing attacks. Payments arising from the victim node would definitely increase in failure rate, but this does not help for nodes that are primarily forwarding nodes.


Updated on: 2023-06-14T02:12:42.180472+00:00