Channel Jamming Bitcoin Lightning Network – Bitcoin Magazine
(Special thanks to Antoine Riard and Gleb Naumenko, if recent research is the basis of this article.)
Channel jamming is one of the outstanding issues of the Lightning Network in terms of things that can interfere with the success of payments routed over it. It’s a well-known problem among developers that has been understood since before the network itself actually went live on the mainnet and started processing even a single satoshi.
So far, the problem hasn’t really had any negative effects on the network, but when considering that fact, it’s important to remember that the network is still relatively small overall. Sales processors have started to support it, as have a few exchanges and many native Lightning/Bitcoin services and businesses, but in reality, not much. The network is still a small thing used mainly by Bitcoiners, and it’s not a very big part of the world at all.
Even further, the amount of bitcoiners who regularly use and use bitcoin in trading settings is an even smaller subset of that already small group. Just because attacks that are possible aren’t happening now, people shouldn’t assume that means they won’t continue to happen as the network grows to a larger scale. The bigger it gets, the more competitive and resilient it will be.
What is Channel Jamming?
The basic concept of channel jamming is to route payments through a Lightning channel you want to jam from yourself to yourself, and then not complete them by releasing the pre-image 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 time-lock for the refund has expired, because they would have no way to enforce their claim for money owed if the preview was released after it was removed. If you block a channel completely by doing this, that channel will not be able to route any payments until after all malicious payments have timed out.
There are two different strategies that can be used here to execute the attack. You can either try to block the routable amount available in a channel, or you can try to block 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 to how large a Bitcoin transaction can be. If you add more than 483 HTLCs per direction to the channel, the transaction to close the channel if necessary will be too large and not valid to be sent to the network. This will make everything in the channel unenforceable on the chain.
So an attacker can either try to unlock all the liquidity in a channel, or try to unlock all the HTLC slots in a channel. Both strategies will render the channel unusable, but slot jamming will generally be cheaper than bulk jamming. The attacker must have coins on the network to be able to perform this attack, so routing the minimum value for an HTCL with 483 capacity will be more cost effective than trying to unlock all the liquidity available in the channel.
Why would anyone want to jam a light channel?
There are many reasons to perform this attack. First, a malicious entity that wants to attack Bitcoin itself can block all the key channels in the “core” of the network to render most of the network useless for routing payments, except for nodes that are very closely connected to each other. This will require many more coins to perform at this scale, but is not something that should be discounted as a possibility the more Bitcoin grows and becomes an alternative to government sanctioned money and payment systems.
Second, a root node, or merchant, may attempt to perform the attack on a competitor to drive fees to them as opposed to their competitors. A merchant selling similar products may block the channels of a competitor to prevent customers from making purchases there, hoping to motivate them to shop at their store instead. A routing node that has similar channel connectivity to another node can block the competing routing node’s channels to render them useless for routing payments. Over time, this will destroy that node’s reputation in terms of routing reliability and, due to similar connectivity, make it more and more likely that users’ wallets will choose the attacker’s node to route payments over the network.
These attacks can be even more capital efficient for the attacker if they loop through a single channel multiple times. If they are close enough to the victim on the network, they can construct a payment route that goes around and continues to go through the victim’s channel. There are limits to how long a payment route can be, so this cannot be done indefinitely, but doing a payment route like this can drastically reduce the amount of coins the attacker needs to block a victim’s channel(s).
Reducing channel jamming attacks
Some basic, partial mitigation measures can be used to increase the cost to attackers and reduce the damage to victims. The first would be a multi-step process for handling HTLCs.
Currently, each HTLC individually adds a new output to the commit transaction for the current channel state. A two-step process might create a single additional output in the commit transaction, and then have a second transaction after the one that has the actual HTLC added to it. This will allow a maximum of 483 multiplied by 483 HTLC tracks per channel (or 233,289 tracks). However, this doesn’t solve anything by itself, and would require extending timelocks because you’re adding an extra transaction to enforce things on-chain, and might actually help the attacker more than the victim if they used this new transaction structure and the victim didn’t. However, it will help in combination with another technique explained in a moment.
The other would be a reactive strategy, where a node that has fallen victim to jamming can simply open a new channel to the same peer as the one being jammed. However, this would require having additional capital to do so, and does not fix the opportunity cost of having the other channel jammed and losing fee revenue, and the new channel may also be blocked afterwards if the attacker has the capital available to do so. .
The third technique would be to bucket HTLC traces. There are currently 483 slots and this is a single slot limit that is universally applied to all payments regardless of the value of the payment. Nodes can create separate buckets with smaller slot limits and apply them to payments of different values, i.e. payments of 100,000 rate or less can only have access to 150 slots. So, routing smaller value payments cannot consume all the available HTLC slots.
Payments of 100,000 bet to 1 million bet can access 300 slots, and 1 million bet to 10 million bet can access a whopping 483 slots. This will significantly increase the cost of capital for an attacker to slot jam, as they will no longer be able to consume all 483 slots with the least possible value payment. Additionally, because HTLC outputs below the dust threshold (currently 546 rate) cannot even be broadcast and enforced on chain, anything below this limit can be handled as a “0 bucket” since no HTLC output is created anyway. Nodes can simply enforce limits on these transactions based on CPU resources used or other metrics to prevent them from being at risk of denial of service, depending on how much they can afford to lose if they are not settled honestly.
Slot bucketing in combination with two-tier HTLC handling can be used to optimize the application of HTLC limits, i.e. higher value payments can use the two-tier structure to create more slots for them per channel because the higher payment value increases the cost of jamming them for an attacker, making 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 bucket tracks and two-stage slot extension, the cause of slot jamming can be made as expensive as the amount of jamming. This will not solve the problem completely, but it increases the minimum cost of executing the attack if it is widely implemented by nodes across the network.
The two comprehensive solutions they have looked at are an upfront/holding time fee to unlock liquidity, and a reputation system using blinded Chaumian tokens. The TLDR for the fee scheme is that a bond for an upfront fee will be paid for routing an HTLC that is expected to take a long time to settle, and the longer it remains unsettled, it will release a fee to each routing node per chunk of time that has gone unsettled . The problem is that enforcing this may lead to the need to close channels if charges are not sent when required, and it will cause legitimate use cases that require long lock times to pay the same higher fee that an attacker attempting channel jamming would.
The reputation scheme will involve a “bond of stake” using zero-knowledge proofs to prove control of Bitcoin as a Sybil defense, then using the bond tied to your reputation to obtain blinded Chaumian tokens from routing nodes that will be redeemed and reissued on the HTLC -is successfully in a privacy-preserving manner. Nodes will issue tokens once per identity, and if an HTLC was not settled or refunded in time, nodes could refuse to reissue the token, thus preventing a user from routing through their node unless they spend time and money to create a new stake bond with different coins to be issued in a new token.
For those who wish to read more about these two solutions, more information can be found in sections five and six of Riard and Naumenko’s research.
It’s also worth noting that if routing nodes were to adopt third-party escrow systems or trust-based credit lines, as I wrote about here , all of these issues 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 rate, the security of their funds, or their ability to enforce it on-chain.
People might not want to hear it, but at the end of the day, if the above solutions to reduce channel congestion for actual channels aren’t 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 the opinions of BTC Inc or Bitcoin Magazine.
