What Happens When Lightning Network Routing Nodes Are Filled With Garbage? In short, this creates a lot of headaches for routing nodes. What was once a smooth, global payment system can be locked into the hands of a savvy scripter with little effort.

In a small group of routing nodes, we successfully tested the attack with funds and demonstrated the "Griefing" attack described by Joost Jager. The attack was dubbed a "sorrow" attack because it wasn't a theft of funds, but it resulted in a victim's Flash Fund being frozen: a major scare. We found that the Grief attack was a serious threat to large "wumbo" channels looking to earn in Bitcoin, but were frozen for a period of time.

This is mostly a "sad" attack: no funds are lost, but the victim may be forced to pay for an expensive channel power closure. This is a known mainnet Lightning vulnerability that needs to be understood and prioritized, especially in the early stages of the Bitcoin Lightning Network.

Thanks to Clark Burkhardt and Phillip Sheppard for their willingness to take part in this test, and to Jager for his tireless efforts to bring attention and importance to this issue. Jager played the role of the attacker in our demo, while Burkhardt and Sheppard joined the ranks as connected victim routing nodes.

How to carry out the attack operation?

The attacker saturates a channel (or channels) with hashed time-locked contracts (HTLCs) that cannot be settled as final payment. These are a special kind of HTLC called HODL invoices. Only 483 of these unresolved HTLCs are needed to overwhelm the channel in each direction. Once these HTLCs enter a channel, any transactions using that same channel direction are impossible, including transactions that cooperate to close that channel.

In theory, the attacker could contact the victim (perhaps sending a message or "onion rings" via the key) and demand a ransom payment to stop the attack. Once the ransom is paid, the attackers can remove the outstanding payments, thus ending the attack. The attack can continue indefinitely, stopping all routing and payment activity in the channel. This freezes the Lightning Channel funds.

By using 483 HTLCs in each direction (inbound and outbound), two payment directions can be stopped in one channel.

Why would an attacker do something like this?

The first motive that comes to mind is asking for a ransom. Such an attack causes pain to the victim, and even if there is no guarantee that the attack will stop, paying the ransom may be attractive to the victim. Contacting victims can be risky for attackers, but ransom payments might not be the only reason attackers do it.

The second incentive to launch a grief attack is to break routing contention. Blocking a competitor's route could increase demand for an attacker-owned route.

As a benchmark, consider that Lightning Labs' Loop node has a constant need for liquidity, and it sometimes pays a payment per million (ppm) (0.25%) rate of 2,500 parts per million. In my experience, they typically drain their 16 million Satyrs of liquidity in about two weeks (5.2% annual growth), but there is competition.

Loop may be willing to pay a higher fee rate (since the liquidity supply is now reduced) if an attacker can disable any competing routes with a lower fee rate. Let’s say Loop will pay 3,000 ppm (0.3%), and since there are no other channels in play, this liquidity can be spent faster. Loop may use that liquidity half the time, say a week. In this example, the attacker's normal rate of return would double to 15.6%. The only cost to the attacker is the cost of running the script on the existing channel, and the psychological cost of acting unethically/destructively on the Lightning Network. Using a single attacker channel, a malicious actor could block approximately nine channels.

What will the victims of this attack experience?

Victims of this attack won't really know if this attack is happening unless they set up some special alerts for pending HTLCs. For Thunderhub users (highly recommended tool), the main screen will display a graph of pending HTLCs along with a warning that the channel can only hold 483 pending HTLCs.

Source: Thunderhub

In fact, my node quickly became unstable and experienced several app crashes, including Thunderhub, which was the only app notifying me of the problem. Then, thanks to my "Satoshis' balance" telegram bot, I got a channel shutdown notification. The channel under attack is automatically closed! This should not have been part of the experiment (For more technical information on involuntary force cooperation, see additional force force data below.)

A test payment using the Burkhardt (salmiak) channel failed due to the attack. This warning reports that Burkhardt's node is offline even though it is online. Source: Thunderhub.

What victims can do to stop the assault？

Once the attack has started, there is basically nothing a victim can do to stop it. The only alternative to stopping an attack in progress is to forcefully close the channel being attacked, which means the terrorists win.

To add insult to injury, force closing a channel pushes the unresolved payment to the on-chain transaction data, triggering a second on-chain transaction to force the originator to close. At 50 sat/vbyte and 483 on-chain transactions, this is easily a 1 million sat price mark to forcefully shut down a channel under attack ($368 channel closure fee at today's prices). Multiple on-chain transactions will only occur if the output exceeds the minimum payment "dust" limit. (See example on testnet.)

The initiator of the Lightning channel pays the closing fee.

text

 https://t.co/z6mAGZxvrC. The closing price is getting more and more expensive.

How to prevent attacks

Jager has been working on a proof-of-concept program to help isolate and defeat attackers. He called his program "Circuit Breaker." Circuit breakers work at the network level, which unfortunately means everyone has to participate for this to be effective.

Apart from that, this problem needs to be prioritized and get the attention of a dedicated engineer/developer to find a better solution. In the Bitcoin Optech newsletter (No. 122 or 126) there is also a good discussion about modifying the protocol.

This attack can be performed today. A miracle that hasn't been used maliciously yet. This reflects the enthusiasm of people using Lightning today so it can become an open, universal payment network. Please share this article as you see fit to encourage and inspire more work to address this issue before actual harm is done.

Additional Technical Information Regarding Involuntary Closing Forces

Here's the log from a node running LND 0.11 when the above unforced shutdown occurs:

2020-11-26 21:24:47.374 [ERR] HSWC: ChannelLink(657759:561:0): No link: ChannelPoint(c37bec006b18df172698a84739ca47128935e0a8666fecd1a843e49b01db207c: 0): Error received from peer: chan_id=7c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc3, ERR= Rejected commit: commit_height=455, invalid_commit_sig=3044022076fd65191eb6305b723fa6012be378413b6326e2786c38db58b4c02e1f3999d202207605ca31de8b4c5b1d9cd20dc1 581dfa2383e0b4e06c8ad4f718ab5c434d8cf5, commit_tx = 02000000017c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc300000000008 a792e8002210d0000000000002200201031cf10a1efef261edd3d0a1a6a953b27bc25bd7150bb2b07afdc69805e02157213000000000000160014de650929042be f58b71783ae1a44834a902a8f2d542ca720, sig_hash=4e0fb804c74376020e4c44a60969b9206eb0aaa9a89b76017d60f23ad5cf63e5, error: remote error

The log shows "invalid_commit_sig", which is a known issue in LND. Presumably this may have happened on reconnect and not a direct result of channel stuttering. Unfortunately, the number of pending HTLCs makes it more likely. Jager helped explain the process: channel blocking –> infinite payment loop (bug) –> node shutting down –> reconnecting –> invalid commit signal (bug) –> channel being forced to close.

The "endless" loop error is a known bug that occurs when the HTLC limit is reached and additional HTLCs are sent. LND will continue to attempt recurring payments rather than ending payment failures. To work around this bug, see LND issue #4656.