6 Bitcoin Lightning Network Vulnerabilities

This is the first article in our two-part series on existing vulnerabilities in Bitcoin’s Lightning Network. Part one details the outstanding vulnerabilities and their risk factors. Part two will examine why these weak spots have never been exploited, what changes may be made to fix them and the developing trade-offs that come from balancing user-friendly applications and air-tight security.

A running joke (or perhaps, an admission) in Bitcoin circles asserts that Bitcoin’s most steadfast proponents are also its most trenchant critics, particularly those in its developer circle. They know how the sausage is made, so to speak, and can see the unsavory side of how the bits and bytes are processed for each new update. 

It’s not that these developers are negative towards Bitcoin; they’re just realistic. 

This could certainly be said about Antoine Riard. The Chaincode Labs developer has authored multiple articles this year on Lightning network attack vectors. He mentions these (and other) vulnerabilities in a new blog post, “Why We May Fail Lightning” as a sobering reminder that, despite the hype, Bitcoin’s secondary network for faster, cheaper payments still needs work before it can support mass deployment. 

And he’s not the only Lightning developer who holds this view. 

In independent Lightning developer Joost Jager’s words, at the heart of these attack vectors are design trade-offs that expose “the balance between building functionality and making [Lightning] secure.” Some features like Neutrino, for instance, which have opened the door for more reliable and user-friendly mobile wallets for Lighting, have also opened up new types of attacks.

Read more: What Is Bitcoin’s Lightning Network?

With every upgrade comes opportunity, both to improve the protocol and to exploit new problems that the new solutions created.

“Lightning is great, but can’t say it is battle-tested. If script kids would be interested, they could take down those shiny new 5 BTC wumbo channels with negligible cost and no effort at all,” Joost Jager, a Lightning network engineer who formerly worked at Lightning Labs, recently tweeted. 

What follows is a list of some of the more worrisome attacks that could be launched on Bitcoin’s Lightning network.

Jager’s thread details a so-called “griefing” attack” that has been possible since Lightning’s inception and affects normal and newly rolled-out wumbo channels.

Lightning channels execute payments on the network using a cryptographic function called hash-time-lock contracts (HTLCs). Lightning channels can only accommodate a few hundred HTLCs. Once this is maxed out the channel can no longer process payments – the funds would be stuck and the channel must be closed. 

Basically, an attacker could freeze bitcoin deposited in a Lightning payment channel by spamming that channel with micropayments. While the attack cannot be used to steal another user’s funds, it could be used by an adversary to sabotage a competitor’s ability to route payments, said Jager. 

Relative to other Lightning Network vulnerabilities, griefing is low on the danger scale since it can only freeze funds, not steal them. However, in theory, the attack could be used by Lightning Service Providers (LSPs), the businesses building on Lightning that manage the bulk of the network’s liquidity, to sabotage a competitor’s business.

For wumbo channels, this is particularly concerning considering the attack could cost pennies to execute while incapacitating channels with a lot of bitcoin locked up. An attacker could also jam multiple channels with this technique if the payments are routed as well, Jager told CoinDesk. 

Since this attack isn’t the most serious, there’s never been a big push from Lightning’s maintainers to fix it. Jager, however, is drafting a firewall solution called “circuitbreaker” so node operators can set limits on how many payments and channels a peer can open with their node.

Flood and loot is similar to the griefing attack discussed by Jager in that it necessitates spamming a payment channel. In this case, however, funds are actually put at risk.

Essentially, an attacker would open channels with one victim (or many victims) and then send payments to another node he or she control without confirming that the payments were received. Each of these channels is coded to close at the same time. 

When this happens, it’s inevitable a handful of these closing transactions will fail because there are so many being broadcast at the same time to the Bitcoin blockchain (when a Lightning payment channel is closed, its funds are sent to on-chain Bitcoin addresses). While some of these transactions are waiting to confirm, the attacker can broadcast their own transactions to the blockchain with a higher fee to claim these funds. 

A flavor of this attack, discovered by Rene Pickhardt, allows an attacker to freeze a channel’s balance in transaction fees and blackmail a victim to resolve the issue.

Flood and loot is more serious than the griefing attack because a victim can actually lose funds from this vulnerability. It’s easier to execute than other vulnerabilities in this article, but it would still require a superb understanding of Lightning to pull off.

The recently pushed anchor channels update, which allows Lightning users to change fees more dynamically when closing a channel, will go a long way toward fixing this vulnerability. 

There are other more complex attacks such as the time-dilation attack that Riard disclosed with Gleb Naumenko. This involves a “sybil attack” (using multiple identities to overwhelm a network) on Bitcoin Lightning nodes. It is particularly effective against nodes that service light clients (that is, Lightning wallets that operate using the bare minimum of data needed to function). 

If an attacker were to spin up hundreds of nodes and crowd all of a Lightning full node’s connections in such a way that the victim is no longer connected to any honest users, the attacker can isolate that node from receiving real network data. 

With the node’s connections “eclipsed,” the attacker can feed the node transaction data at a slower rate than normal. Once the attacker closes its Lightning channels with the victim, he or she could steal funds from that channel because its host node will not see the channel’s closing transaction on the blockchain because it is not receiving data quickly enough. 

The attack is particularly threatening against light clients because these Lightning wallets only receive blockchain data one block at a time, as opposed to a full Lightning client that always has a copy of the blockchain’s transaction history.

Light clients comprise the bulk of consumer-grade Lightning Network wallets from a handful of providers such as Lightning Labs, Phoenix, Blue Wallet, and other Lightning service providers. When they authored the paper in June 2020, Riard and Naumenko estimated a successful attack at scale could eclipse 47% of newly deployed light clients. 

The attack is serious in that a victim could lose funds. That said, the attack does require the malicious actor to operate – and coordinate – hundreds of nodes to successfully eclipse a victim. This can certainly be accomplished, but it would take a very proficient hacker with a stellar Bitcoin and Lightning Network acumen.

This attack is trickier than the others in a way because there’s no single solution you can deploy on the Lightning protocol; because this attack also relies on manipulation of on-chain data, it requires coordinating with development on Bitcoin’s blockchain, as well, to find a sustainable solution. 

Another attack that requires incongruent transaction data is known as a “pinning attack.” 

To exploit this vulnerability, a sophisticated attacker blocks a channel’s closing transaction by broadcasting conflicting transactions to separate nodes with dissimilar mempools. (Remember: There is no uniform pool for pending transactions on Bitcoin’s network; some nodes receive transactions others don’t based on the distribution of the peer-to-peer network connections, so each mempool is different). 

Using a variety of techniques, one of which involves setting a low enough fee on a closing transaction to ensure it is not confirmed before the channel’s timelock expires, an attacker can trick a victim into closing his or her channels improperly, and thus steal individual transactions.

Funds can be stolen using this attack, but as we have caveated with eclipse and flood and loot, it also requires impressive technical knowledge on behalf of the attacker. 

In part, the anchor outputs update will help to mitigate this attack vector. But as with the eclipse attack, this attack relies on coordination with Bitcoin’s blockchain, so a solution will have to factor in both networks.

Some of these vulnerabilities are more feasible (and costly) than others, but the good news is that no one has ever exploited them. We’ll discuss why that is in part two of this series, as well as present some of the fixes that are in the works. 

Additionally, Riard and Jager will share their thoughts on the future of the Lightning Network and the tricky balance developers must strike between user experience and security as they build the protocol. 

Coming tomorrow: Lightning Network Attack Vectors Have Never Been Hit – Some Pressure May Help the Network