Is Channel Jamming A Threat To Bitcoin’s Lightning Network?

Channel jamming has emerged as a potential attack vector for Bitcoin’s Lightning Network. But does it pose a real threat?

(Special thanks to Antoine Riard and Gleb Naumenko, whose recent research is the basis of this article.)

Channel jamming is one of the outstanding problems of the Lightning Network in terms of things that could disrupt the success of payments routed across it. It is a widely known problem among developers that has been understood since before the network itself actually went live on mainnet and started processing even a single satoshi.

So far the issue has not really had any negative effects on the network, but when considering that fact, it is important to keep in mind that the network is still, in the grand scheme of things, relatively small. Merchant processors have started supporting it, as have a few exchanges and lots of Lightning/Bitcoin native services and businesses, but in reality, that is not much. The network is still very much a small thing predominantly used by Bitcoiners, and that is not a very large portion of the world at all.

Even further, the amount of Bitcoiners who regularly spend and use their bitcoin in commerce settings is an even smaller subset of that already small group. Just because attacks that are possible are not occurring now, people should not assume that means they will continue not to occur when the network grows to a larger scale. The bigger it gets, the more competitive and adversarial it will become.

What Is Channel Jamming?

The basic concept of channel jamming is to route payments through a Lightning channel you wish to jam from yourself to yourself, and then to not finalize them by releasing the preimage to the payment hash in the hashed timelock contracts (HTLCs). The victim(s) will not be able to remove the HTLCs from their channel until after the timelock for the refund has expired, because they would have no way to enforce their claim to money they are owed if the preimage was released after removing it. If you completely jam a channel by doing this, then that channel will be incapable of routing any payments until after the timelock expires on all the malicious payments.

There are two different strategies that can be employed here in order to perform the attack. You can either try and jam the routable amount available in a channel, or you can try and jam up all the individual HTLC slots in a channel. A Lightning channel can only have 483 pending HTLCs in each direction it can route — this is because there is a maximum size limit of how big a Bitcoin transaction can be. If you add more than 483 HTLCs per direction in the channel, the transaction to close the channel if needed would be too big and not valid to submit to the network. This would make everything in the channel unenforceable on chain.

So, an attacker can either try and lock up all the liquidity in a channel, or try and lock up all the HTLC slots in a channel. Either strategy would make the channel unusable, but slot jamming is generally going to be cheaper than amount jamming. The attacker needs to have coins on the network in order to perform this attack, so routing the minimum-allowed value for an 483-capacity HTCL is going to be more cost effective than trying to lock up all the liquidity available in the channel.

Why Would Someone Want To Jam A Lighting Channel?

There are many reasons to perform this attack. Firstly, a malicious entity who wants to attack Bitcoin itself could jam all of the key channels at the “core” of the network in order to make most of the network unusable for routing payments, except for nodes that are very closely connected to each other. This would require a lot more coins to perform at this scale, but 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.

Secondly a routing node, or merchant, could attempt to perform the attack on a competitor in order to drive fees to them as opposed to the competition. A merchant selling similar products could jam the channels of a competitor to prevent customers from making purchases there, in hopes of incentivizing them to shop at their store instead. A routing node that has similar channel connectivity as another node could jam the competing routing node’s channels in order to make them unusable for routing payments. Over time this would destroy that node’s reputation in terms of routing reliability, and because of similar connectivity, make it more and more likely that users’ wallets would choose the attacker’s node in order to route payments across the network.

These attacks can be even more capital efficient for the attacker if they circularly route through a single channel multiple times. If they are close enough to the victim on the network, they can construct a payment route that loops around and keeps going through the victim’s channel. There are limits to how long a payment route can be, so this can’t be done infinitely, but doing a looping payment route like this can drastically lower the amount of coins the attacker needs to completely jam a victim’s channel(s).

Mitigating Channel Jamming Attacks

Some basic, partial mitigations could be applied in order to increase the cost for attackers and mitigate the damage for the victims. The first would be a multi-stage process for handling HTLCs.

Currently, each HTLC individually adds a new output in the commitment transaction for the current channel state. A two-stage process could create a single extra output in the commitment transaction, and then have a second transaction after that which has the actual HTLC added to it. This would allow a maximum of 483 multiplied by 483 HTLC slots per channel (or 233,289 slots). However, this does not really fix anything by itself, and would require extending the timelocks because you are adding an extra transaction for enforcing things on-chain, and could actually help the attacker more than the victim if they utilized this new transaction structure and the victim did not. It, however, will help in combination with another technique explained momentarily.

The second would be a reactive strategy, where a node who has fallen victim to jamming can simply open a new channel to the same peer as the one being jammed. This, however, would require having extra capital to do so, does not fix the opportunity cost of having the other channel jammed and losing fee revenue, and the new channel could be subsequently jammed as well if the attacker has the capital available to do so.

The third technique would be to bucket HTLC slots. Currently there are 483 slots, and this is a single slot limit applied universally to all payments regardless of the value of the payment. Nodes could create separate buckets of smaller slot limits and apply them to payments of different values, i.e., payments of 100,000 sats or smaller could only have access to 150 slots. So, routing payments of smaller value cannot consume all of the available HTLC slots.

Payments of 100,000 sats to 1 million sats could have access to 300 slots, and 1 million sats to 10 million sats could have access to the full 483 slots. This would significantly raise the capital cost of an attacker to slot jam, as they would no longer be able to consume all 483 slots with the smallest value payment possible. Additionally, because HTLC outputs below the dust threshold (currently, 546 sats) cannot even be broadcast and enforced on chain, anything below this limit could be handled as a “0 bucket” since no HTLC output is created anyway. Nodes could simply enforce limits on these transactions based on CPU resources used or other metrics to prevent them from becoming denial-of-service risks, depending on how much they can afford to lose if they are not settled honestly.

Slot bucketing in combination with two-stage HTLC handling can be used to optimize the application of HTLC limits, i.e., higher value payments can use the two-stage structure to create more slots for them per channel because the higher payment value increases the cost of jamming them for an attacker, making the abuse of a higher slot limit to perform jamming attackers less likely.

In their research cited above, Riard and Naumenko have shown that with the optimal combination of bucketing slots and two-stage slot extension, the cause of slot jamming can be made as expensive as amount jamming. This would not comprehensively solve the problem, but it does raise the minimum cost of performing the attack if widely implemented by nodes across the network.

The two comprehensive solutions they have looked at are an up-front/hold-time fee for locking up liquidity, and a reputation system using blinded Chaumian tokens. The TLDR of the fee scheme is that a bond for an up-front fee would be paid for routing an HTLC that is expected to take a long time to settle, and the longer it remains unsettled, it would release a fee to each routing node per chunk of time that has passed without settlement. The problem is that enforcing this could lead to the need to close channels if fees are not sent when required, and it will cause legitimate use cases that require long lock-up times to pay the same higher fee that an attacker attempting channel jamming would.

The reputation scheme would involve a “stake bond” using zero-knowledge proofs to prove control of Bitcoin as a Sybil defense, and then using the bond tied to your reputation to acquire blinded Chaumian tokens from routing nodes that would be redeemed and reissued upon HTLCs successfully settling in a privacy-preserving way. Nodes would issue tokens once per identity, and if an HTLC was not settled or refunded in a timely manner, nodes could refuse to reissue the token, thus preventing a user from routing through their node unless they spend the time and money to create a new stake bond with different coins to be issued in a fresh token.

For those who wish to read more about these two solutions, more information can be found in sections five and six in Riard’s and Naumenko’s research.

It is also worth noting that if routing nodes were to adopt third-party-based escrow systems or trust-based lines of credit, as I wrote about here, all of these problems related to channel jamming would cease to affect them. This would be a huge change in the trust model for routing nodes, but it would have zero effect on people using real Lightning channels to send and receive sats, the security of their funds or their ability to enforce that on chain.

People might not want to hear it, but at the end of the day, if the solutions above for mitigating channel jamming for actual channels are not enough, these third-party systems are always a potential option.

This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Read More

(Special thanks to Antoine Riard and Gleb Naumenko, whose recent research is the basis of this article.)

Channel jamming is one of the outstanding problems of the Lightning Network in terms of things that could disrupt the success of payments routed across it. It is a widely known problem among developers that has been understood since before the network itself actually went live on mainnet and started processing even a single satoshi.

So far the issue has not really had any negative effects on the network, but when considering that fact, it is important to keep in mind that the network is still, in the grand scheme of things, relatively small. Merchant processors have started supporting it, as have a few exchanges and lots of Lightning/Bitcoin native services and businesses, but in reality, that is not much. The network is still very much a small thing predominantly used by Bitcoiners, and that is not a very large portion of the world at all.

Even further, the amount of Bitcoiners who regularly spend and use their bitcoin in commerce settings is an even smaller subset of that already small group. Just because attacks that are possible are not occurring now, people should not assume that means they will continue not to occur when the network grows to a larger scale. The bigger it gets, the more competitive and adversarial it will become.

What Is Channel Jamming?

The basic concept of channel jamming is to route payments through a Lightning channel you wish to jam from yourself to yourself, and then to not finalize them by releasing the preimage to the payment hash in the hashed timelock contracts (HTLCs). The victim(s) will not be able to remove the HTLCs from their channel until after the timelock for the refund has expired, because they would have no way to enforce their claim to money they are owed if the preimage was released after removing it. If you completely jam a channel by doing this, then that channel will be incapable of routing any payments until after the timelock expires on all the malicious payments.

There are two different strategies that can be employed here in order to perform the attack. You can either try and jam the routable amount available in a channel, or you can try and jam up all the individual HTLC slots in a channel. A Lightning channel can only have 483 pending HTLCs in each direction it can route — this is because there is a maximum size limit of how big a Bitcoin transaction can be. If you add more than 483 HTLCs per direction in the channel, the transaction to close the channel if needed would be too big and not valid to submit to the network. This would make everything in the channel unenforceable on chain.

So, an attacker can either try and lock up all the liquidity in a channel, or try and lock up all the HTLC slots in a channel. Either strategy would make the channel unusable, but slot jamming is generally going to be cheaper than amount jamming. The attacker needs to have coins on the network in order to perform this attack, so routing the minimum-allowed value for an 483-capacity HTCL is going to be more cost effective than trying to lock up all the liquidity available in the channel.

Why Would Someone Want To Jam A Lighting Channel?

There are many reasons to perform this attack. Firstly, a malicious entity who wants to attack Bitcoin itself could jam all of the key channels at the “core” of the network in order to make most of the network unusable for routing payments, except for nodes that are very closely connected to each other. This would require a lot more coins to perform at this scale, but 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.

Secondly a routing node, or merchant, could attempt to perform the attack on a competitor in order to drive fees to them as opposed to the competition. A merchant selling similar products could jam the channels of a competitor to prevent customers from making purchases there, in hopes of incentivizing them to shop at their store instead. A routing node that has similar channel connectivity as another node could jam the competing routing node’s channels in order to make them unusable for routing payments. Over time this would destroy that node’s reputation in terms of routing reliability, and because of similar connectivity, make it more and more likely that users’ wallets would choose the attacker’s node in order to route payments across the network.

These attacks can be even more capital efficient for the attacker if they circularly route through a single channel multiple times. If they are close enough to the victim on the network, they can construct a payment route that loops around and keeps going through the victim’s channel. There are limits to how long a payment route can be, so this can’t be done infinitely, but doing a looping payment route like this can drastically lower the amount of coins the attacker needs to completely jam a victim’s channel(s).

Mitigating Channel Jamming Attacks

Some basic, partial mitigations could be applied in order to increase the cost for attackers and mitigate the damage for the victims. The first would be a multi-stage process for handling HTLCs.

Currently, each HTLC individually adds a new output in the commitment transaction for the current channel state. A two-stage process could create a single extra output in the commitment transaction, and then have a second transaction after that which has the actual HTLC added to it. This would allow a maximum of 483 multiplied by 483 HTLC slots per channel (or 233,289 slots). However, this does not really fix anything by itself, and would require extending the timelocks because you are adding an extra transaction for enforcing things on-chain, and could actually help the attacker more than the victim if they utilized this new transaction structure and the victim did not. It, however, will help in combination with another technique explained momentarily.

The second would be a reactive strategy, where a node who has fallen victim to jamming can simply open a new channel to the same peer as the one being jammed. This, however, would require having extra capital to do so, does not fix the opportunity cost of having the other channel jammed and losing fee revenue, and the new channel could be subsequently jammed as well if the attacker has the capital available to do so.

The third technique would be to bucket HTLC slots. Currently there are 483 slots, and this is a single slot limit applied universally to all payments regardless of the value of the payment. Nodes could create separate buckets of smaller slot limits and apply them to payments of different values, i.e., payments of 100,000 sats or smaller could only have access to 150 slots. So, routing payments of smaller value cannot consume all of the available HTLC slots.

Payments of 100,000 sats to 1 million sats could have access to 300 slots, and 1 million sats to 10 million sats could have access to the full 483 slots. This would significantly raise the capital cost of an attacker to slot jam, as they would no longer be able to consume all 483 slots with the smallest value payment possible. Additionally, because HTLC outputs below the dust threshold (currently, 546 sats) cannot even be broadcast and enforced on chain, anything below this limit could be handled as a “0 bucket” since no HTLC output is created anyway. Nodes could simply enforce limits on these transactions based on CPU resources used or other metrics to prevent them from becoming denial-of-service risks, depending on how much they can afford to lose if they are not settled honestly.

Slot bucketing in combination with two-stage HTLC handling can be used to optimize the application of HTLC limits, i.e., higher value payments can use the two-stage structure to create more slots for them per channel because the higher payment value increases the cost of jamming them for an attacker, making the abuse of a higher slot limit to perform jamming attackers less likely.

In their research cited above, Riard and Naumenko have shown that with the optimal combination of bucketing slots and two-stage slot extension, the cause of slot jamming can be made as expensive as amount jamming. This would not comprehensively solve the problem, but it does raise the minimum cost of performing the attack if widely implemented by nodes across the network.

The two comprehensive solutions they have looked at are an up-front/hold-time fee for locking up liquidity, and a reputation system using blinded Chaumian tokens. The TLDR of the fee scheme is that a bond for an up-front fee would be paid for routing an HTLC that is expected to take a long time to settle, and the longer it remains unsettled, it would release a fee to each routing node per chunk of time that has passed without settlement. The problem is that enforcing this could lead to the need to close channels if fees are not sent when required, and it will cause legitimate use cases that require long lock-up times to pay the same higher fee that an attacker attempting channel jamming would.

The reputation scheme would involve a “stake bond” using zero-knowledge proofs to prove control of Bitcoin as a Sybil defense, and then using the bond tied to your reputation to acquire blinded Chaumian tokens from routing nodes that would be redeemed and reissued upon HTLCs successfully settling in a privacy-preserving way. Nodes would issue tokens once per identity, and if an HTLC was not settled or refunded in a timely manner, nodes could refuse to reissue the token, thus preventing a user from routing through their node unless they spend the time and money to create a new stake bond with different coins to be issued in a fresh token.

For those who wish to read more about these two solutions, more information can be found in sections five and six in Riard’s and Naumenko’s research.

It is also worth noting that if routing nodes were to adopt third-party-based escrow systems or trust-based lines of credit, as I wrote about here, all of these problems related to channel jamming would cease to affect them. This would be a huge change in the trust model for routing nodes, but it would have zero effect on people using real Lightning channels to send and receive sats, the security of their funds or their ability to enforce that on chain.

People might not want to hear it, but at the end of the day, if the solutions above for mitigating channel jamming for actual channels are not enough, these third-party systems are always a potential option.

This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Bitcoin Magazine – Bitcoin News, Articles and Expert Insights