It is a problem that is well recognized in the developer community and has been understood ever since before the network itself went live on mainnet and started processing even a single satoshi.

In spite of the fact that the problem has not actually caused any bad impacts on the network as of yet, it is essential to keep in mind that in the broad scheme of things, the network is still on the smaller side. It is being supported by merchant processors, a few exchanges, and a large number of Lightning Network and Bitcoin-native services and businesses, but in all honesty, this is not a significant amount of progress. The network is still very much a little thing that is largely used by Bitcoiners, which is not a very huge section of the world at all. Nonetheless, Bitcoiners make up the majority of users on the network.

Even further, the number of Bitcoin users who routinely spend and use their cryptocurrency in commercial contexts constitutes an even smaller portion of that already limited population. People shouldn't believe that just because such attacks aren't happening right now that they won't start happening as the network scales up to a higher size since that's not necessarily the case. When it grows to a certain size, it will inevitably become more antagonistic and competitive.

What Does It Mean to Jam Channels?

Channel jamming is accomplished by first routing payments through a Lightning channel that you wish to jam from yourself to yourself, and then failing to finalize those payments by releasing the preimage to the payment hash in the hashed timelock contracts. This is the fundamental idea behind channel jamming (HTLCs). Because they would have no way to enforce their claim to money they are owed if the preimage was released after removing it, the victim (or victims) will not be able to remove the HTLCs from their channel until after the timelock for the refund has expired. This is because they will not be able to remove the HTLCs until after the timelock has expired. If you totally jam a channel by doing this, then that channel will be unable to route any payments until the timelock on all of the malicious payments has run its course and expired.

There are two distinct approaches that one might take in this situation in order to carry out the attack successfully. You have the option of either attempting to jam the routable amount that is currently available in a channel or attempting to jam each of the individual HTLC slots that are present in a channel. Because there is a cap on the total size of a Bitcoin transaction, a Lightning channel can only have a maximum of 483 pending HTLCs in each direction it can route. This is because the maximum size of a Bitcoin transaction is limited. If you add more than 483 HTLCs in each direction to the channel, the transaction to terminate the channel, in the event that it is necessary, would be too large and would not be valid to send to the network. Because of this, everything in the channel would be rendered unenforceable on the chain.

An adversary may therefore attempt to either lock up all of the liquidity in a channel or all of the HTLC slots in a channel, both of which are viable options. The channel would be rendered useless regardless of the tactic used, however slot jamming is likely to be less expensive than amount jamming in most cases. Because the attacker has to have coins on the network in order to carry out this attack, it is going to be more cost effective for them to route the minimum-allowed value for a 483-capacity HTCL rather than attempt to lock up all of the liquidity that is now available in the channel.

What would motivate someone to intentionally interfere with a lighting channel?

There are a lot of different motivations to carry out this assault. To begin, a malicious entity that wants to attack Bitcoin itself could jam all of the key channels at the "core" of the network in order to render the majority of the network unusable for routing payments, with the exception of nodes that are very closely connected to each other. This would allow the malicious entity to attack Bitcoin directly. This would require a lot more coins to perform at this scale, but it is not something that should be discounted as a possibility with the more that Bitcoin grows and becomes an alternative to government-sanctioned money and payment systems. This is not something that should be discounted as a possibility with the more that Bitcoin becomes an alternative to government-sanctioned money and payment systems.

Second, a routing node or a merchant could try to undertake the assault on a rival in order to divert fees away from the rival in question and toward themselves. A retailer who sells products that are comparable to those of a rival could disrupt the distribution channels of the rival's customers in an effort to persuade those customers to make their purchases at the retailer's own store instead. A routing node that shares the same channel connectivity as another node may jam the channels of a rival routing node in order to render them inoperable for the purpose of payment routing. Because of the similar connectivity, it will become increasingly likely that users' wallets will select the attacker's node in order to route payments across the network. This will cause the node's reputation to suffer over time in terms of the reliability of its routing, and it will make it more likely that users' wallets will choose the attacker's node.

If the attacker performs these operations in a circular fashion, routing through a single channel numerous times, they can be even more efficient in their use of capital. If they are located in close enough proximity to the victim on the network, they will be able to design a payment route that goes around the victim's channel and continues to go through it. A payment route can only be a certain length, thus this can't be done indefinitely. However, using a payment route that loops like this can significantly reduce the number of coins an attacker needs to totally jam a victim's channel (s).

Mitigating Channel Jamming Attacks

It is possible to implement a few fundamental and partial mitigations in order to raise the bar for attackers and reduce the severity of the damage suffered by victims. The first option would be a procedure consisting of multiple stages for dealing with HTLCs.

At the moment, the commitment transaction for the current channel state is updated with the addition of a new output from each individual HTLC. It is possible for a two-stage process to generate a single additional output during the commitment transaction, and then for there to be a further transaction that takes place after that and adds the actual HTLC to it. This would make it possible to have a maximum of 483 HTLC slots multiplied by 483 on each channel (or 233,289 slots). However, this does not really fix anything by itself, and it would require increasing the timelocks because you are adding an additional transaction for enforcing things on-chain. Additionally, this could actually help the attacker more than the victim if the attacker utilized this new transaction structure and the victim did not. However, using it in conjunction with another strategy, which will be discussed in a moment, will be beneficial. The second type of strategy is called a reactive strategy, and it involves opening a new channel to the same peer as the one that is being jammed. This allows a node that has been disrupted by jamming to continue communicating with its peers. This, however, would need having additional funds in order to accomplish, does not address the opportunity cost of having the other channel jammed and losing fee revenue, and the new channel might afterwards be jammed as well if the attacker has the financial resources available to do so.

The bucketing of HTLC slots is the third method that could be used. There are currently 483 slots available, and this limit is a single slot that is applied consistently across the board to any and all payments irrespective of the amount paid. Nodes might build distinct buckets of lesser slot restrictions and apply them to payments of different values; for example, payments of 100,000 sats or less might only be able to access 150 slots. This flexibility would allow nodes to accommodate a wider range of transaction sizes. Therefore, the routing of payments with a lower value cannot use up all of the HTLC slots that are available.

Payments ranging from 100,000 sats to 1 million sats are eligible for access to 300 slots, while payments ranging from 1 million sats to 10 million sats are eligible for access to all 483 seats. Slot jamming would become substantially more expensive for an attacker as a result of this change because the attacker would no longer be able to fill all 483 available slots while paying the least amount of money possible. In addition, HTLC outputs that are lower than the dust threshold (which is now set at 546 sats) cannot even be broadcast and enforced on chain. As a result, anything that falls below this limit could be treated as a "0 bucket" because there will be no HTLC output made whatsoever. Depending on how much they can afford to lose if the transactions are not settled honestly, nodes could simply impose limits on the number of these transactions based on the amount of CPU resources that were used or on some other metric. This would prevent the transactions from becoming potential risks of denial-of-service attacks.

Slot bucketing, in conjunction with two-stage HTLC handling, can be used to optimize the application of HTLC limits. This means that higher value payments can use the two-stage structure to create more slots for them per channel. This is possible due to the fact that a higher payment value makes it more difficult and expensive for an attacker to jam those payments. As a result, the likelihood of an attacker abusing a higher slot limit in order to perform jamming attacks is reduced.

The above-mentioned study by Riard and Naumenko demonstrates that slot jamming can be made as costly as amount jamming by employing the best mix of bucketing slots and two-stage slot extension. If widely adopted by nodes across the network, this would not eliminate the problem entirely, but it would increase the minimal cost of performing the assault.

An upfront/hold-time cost for locking up liquidity and a reputation system based on blinded Chaumian coins are the two comprehensive options they have considered so far. The short version of the fee scheme is that when routing an HTLC that is predicted to take a long time to settle, an up-front fee bond is paid, and the bond releases a charge to each routing node based on how much time has passed since the HTLC was initially routed. The problem with this is that it could force us to close channels if payments aren't received on time, and it would force legitimate use cases that need long lock-up durations to pay the same higher charge as an attacker trying to jam the channel.

Using zero-knowledge proofs to demonstrate Bitcoin control as a Sybil defense, a "stake bond" could be used in the reputation scheme; this bond could then be used to purchase blinded Chaumian tokens from routing nodes, which could be redeemed and reissued upon the successful settlement of HTLCs without compromising privacy. Nodes would only issue tokens once per identity, and they could refuse to reissue a token if an HTLC wasn't settled or refunded in a timely manner. This would prevent a user from routing through their node unless the user took the time and effort to create a new stake bond with different coins to be issued in a new token.

Readers interested in learning more about these two options can refer to Chapters 5 and 6 of Riard and Naumenko's study. It's also worth mentioning that all of these channel-related concerns would disappear if routing nodes adopted third-party escrow systems or trust-based lines of credit, as I discussed in this article. While this would have a profound impact on the trust model for routing nodes, it would not affect the security of funds or the ability to enforce that on chain for those who use genuine Lightning channels to transfer and receive sats.[rb_related title="More Read" style="light" total="4"]

No one likes to hear it, but if the aforementioned methods of preventing and/or reducing channel jamming for real channels are insufficient, these external systems should be considered.