Channel Jamming Attacks on the Lightning Network: A Deep-Dive

In May this year, Bitcoin Core contributors Gleb Naumenko and Antoine Riard proposed the use of Fidelity Bonds for LN Routing to prevent channel jamming, a type of denial-of-service (DOS) attack that can occur on the Lightning Network.

Channel jamming, first described in 2015 by Rusty Russell, usually describes a scenario in which an attacker sends a payment to themselves through a series of routing nodes and then stops responding. However, channel jamming can also occur when a laggy receiver node does not complete a payment. As a consequence, the funds are locked in a routing channel until the payment times out, leaving them unavailable for other payments on the network.

Previous proposals to prevent channel jamming require upfront fee payments, an overly burdensome step for honest users. Naumenko and Riard seek to attack the issue from a different angle. I read about their proposal in the latest Bitcoin Optech Newsletter and decided to reach out to Naumenko to find out more.

Hi Gleb. Why did you write the proposal, and what are you hoping to achieve with it?

Channel jamming is a general spam or denial-of-service problem. Usually, this can be resolved by confirming you have a unique or scarce resource to gain access. For example, Twitter requires a user to have a mobile phone number or email to sign up. In Bitcoin, we have to think of something more neutral, not linked to identity or controlled by some central authority. 

Bitcoin uses Proof-of-Work and mining to limit block production so that blocks are not created too quickly and the network does not grow too fast. On the Lightning Network, Proof-of-Work wouldn't work as an attacker can acquire special hardware, such as a miner, making it too expensive for a user to compete. 

With the upfront payment solution, which requires all users to pay a flat fee, restrictions would penalize honest users, and it wouldn't be 100% robust as a bad actor could just allocate capital to the attack. Honest users would have to pay the fee even if the payments fail, which is not optimal. 

In our solution, as long as a user can verify UTXO ownership (in a UTXO set), but avoid pointing to a particular UTXO, and is willing to stake an amount specified in that set, the channel will allow you to send a payment. For example, a user could state, “I will prove that I own one UTXO among all UTXOs between 0.5 BTC and 1 BTC.”

What are some of the scenarios in which channel jamming can occur? Is it primarily caused by a bad actor, or can it also be accidentally triggered if a user is not as technically adept?

Channel jamming is possible because the Lightning Network has limited permissive restrictions and routing nodes don't charge much for fees. Most people would first consider an active attacker, but this can also occur when nodes don’t manage their capital or handle errors correctly, resulting in funds being accidentally locked in the channel.

To jam the channel, a bad actor would need to lock just one payment in that routing channel for the attack to succeed. Someone might jump channels and even spend money on this if their aim is to gain an advantage over competitors. Additionally, you could compromise certain nodes, making routing only possible through the attacker’s nodes, in order to steal fees. In the future, when routing becomes an economic activity, we'll want to actively consider this scenario.

What is required for your proposal to be implemented, and do you see any barriers or technical changes that would prevent it from being adopted?

The biggest challenge is the novel cryptography we need to employ. Revealing your coins is very simple; you just digitally sign as if signing a fake transaction, but it's going to be a privacy nightmare. So the idea is to make this possible using zero-knowledge proofs. I prove that I own bitcoin without revealing my UTXO, which, unfortunately, requires some advanced cryptographic knowledge. 

Even though I’ve seen Jonas Nick post a prototype of the code, I think the idea requires a lot of review and testing. We need to justify the effort and the additional complexity, which is pretty major. The next task will be to measure how expensive and difficult it is to perform a channel jamming attack, then apply the same model to the solution we propose. 

If we see it's ten times more expensive, then we should consider the effort. If our solution is implemented and it's a thousand times more expensive for an attacker, then it's probably a good solution and we should adopt it. If it's only twice as expensive, we shouldn't spend time on it and instead consider a different option.

It sounds like further research is required. How would you estimate the magnitude of this proposal?

The idea of proving bitcoin ownership without revealing your UTXO has different applications. I can have a separate peer-to-peer Bitcoin network where blocks are much faster, but I only allow people in who can supply proof they own some bitcoin. It's not like we're making a new feature, but I think it's pretty big—although maybe not as sexy, because we're just making things work. But maybe this will help us improve other parts of the system.

What other improvements would you personally like to see in Bitcoin?

I'm really interested in revisiting the ideas we considered to be too experimental a couple of years ago, like DLC financial contracts. Discrete Log Contracts are a second layer protocol for Lightning or Bitcoin, but they scale significantly better over the Lightning Network. 

DLC has all this Oracle fancy stuff that can enable real contracts, beyond sending money and multisig. It unlocks the financial future we might need for Bitcoin: stocks, futures, and derivatives. A couple of years ago, we might have fought over this thinking it's too early, but maybe now it's time. The idea is mature, and perhaps we're ready now. 

We also need more developers. We're seeing many new grants being announced, and I hope this will give us more developers with fresh insight, open-mindedness, and maybe suggestions to expand the network and improve its security.

Final question. Are you looking for additional help with your proposal, and if so, what particular skills are you looking for in contributors?

We're going to start by building an economic model for the existing problem, without any solutions. We want to see what is the most efficient jamming an attacker can do, and see what they can achieve for the smallest cost. If you're interested in academic research or modeling, reach out, otherwise, just be curious, read the proposal, and participate in the discussion on the Lightning-Dev mailing list.