The Lightning Network is a young protocol, and it’s going through some technical growing pains as its tech stack grows and its network expands. While most of the vulnerabilities (covered in part one of this series) are neither protocol-breaking nor easy to exploit, they’re still reminders that improvements come with trade-offs – and that security and usability are two sides of the same coin.
This is the second article in our two-part series on existing vulnerabilities in Bitcoin’s Lightning Network. Part one detailed 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.
Vulnerable, but never exploited
For all of the Lightning network protocol’s vulnerabilities, no one has exploited them yet. It seems that, right now, they’re either too difficult to pull off for most hackers or there’s not enough at stake in Lightning channels to justify the effort, Joost Jager, an independent Lightning network engineer, told CoinDesk.
Also, most everyone using Lightning right now is friendly and non-adversarial, so things have remained generally peaceful on Bitcoin’s scaling frontier.
To some extent, however, Jager would welcome a little adversity. After all, it’s all well and good to have vulnerabilities that no one exploits, but what happens when the “kumbaya” stops, attackers get savvy and Lightning has enough money in it to justify an attack?
Read more: What Is Bitcoin’s Lightning Network?
Before that day comes, Jager would like to see more “battle testing” of Lightning’s network so these attack vectors aren’t ignored until they can’t be any longer.
“I think it would help if Lightning would become a target for hackers. Because right now everything is so friendly; it’s not really tested. I think it would be good at this stage because it helps you set your priorities. If you’re under attack, then you need to address the attack. And if you can’t, then there are fundamentals you have to address.”
“It almost feels like you’re going to prepare Earth for a meteor that will destroy life but it hasn’t happened! If there’s no actual attack then it’s hard to keep attention on these problems.”
As Jager pointed out, all the dominant actors on the network today are more focused on collaboration than subterfuge.
“All of the people building at the moment are all friendly and just want to make Lightning work and succeed,” Jager told CoinDesk.
Indeed, the total number of technical savants who understand Bitcoin and its Lightning Network inside and out could fit inside a small room. Couple this with the fact that Lightning isn’t a large enough honeypot for hackers to bother exploiting and you have an answer for why the network hasn’t been targeted by malicious actors.
“Exploiting LN requires a strong knowledge about both Bitcoin and Lightning internals. As of today this knowledge isn’t widespread, which is a good starter to explain why it’s not exploited,” Antoine Riard, a Lightning Developer for Chaincode Labs, told CoinDesk.
“From a pure, holistic viewpoint, if you have this level of skills it’s likely more lucrative to steal from yet another insecure blockchain where there is far more funds on it than in the sum of all Lightning channels.”
Can we fix it? Yes, but…
Nevertheless, developers are already working on various fixes – but it’s not so simple as just deploying an update.
Of the vulnerabilities discovered (and described in part one), the so-called griefing attack – where an attacker can block a channel from sending or receiving payments by spamming it with hash-time-lock contracts (HTLCs) – is the oldest and the least serious since funds cannot be stolen through the attack, only frozen. Others such as flood and loot, another attack that involves spamming a victim’s payment channels with HTLCs, can result in loss of funds.
Others still, such as pinning and time-dilation attacks, involve exploiting Lightning’s fee structure to compromise a victim’s payment channel balance.
For those vulnerabilities that capitalize on the Lightning Network’s fee mechanisms, Riard told CoinDesk, a new transaction update, rolled out in April with an LND update, “takes a step forward” to address these weak points. “Anchor channels” will allow users to update fees on the go when closing channels to expedite their confirmations on chain.
This experimental feature should improve channel closing success rates and should mitigate the attack vectors for many of the fee-related vulnerabilities. With anchor channels, would-be victims can front-run bad actors by making sure their channels will close before something malicious comes to pass.
Still, this improvement has exposed a fresh vulnerability that Riard disclosed this September wherein an attacker can essentially cheat a “justice transaction” (a mechanism in Lightning that punishes bad actors who try to cheat their peers by seizing their channel balances).
The new vulnerability, surfacing as it has from a protocol upgrade, is a salient reminder to Riard that no updated feature will be a cure-all for Lightning’s weak points.
“What we should be reminded of is that each class of vulnerability needs its own solution; there is no silver bullet solving all of them. Eclipse attacks need better network-partition resistance. Pinning attacks require better fee models. Some of these engineering solutions may be integrated in Bitcoin Core because it’s a common factor beyond any LN implementation.”
Lightning Network vulnerability fixes have their limits
Indeed, in some cases, updating Lightning alone might not cement a fix. To address the pinning attack, for instance, Riard said that “transaction relay and fee bumping improvements for Bitcoin’s main network” will be necessary. He considers this attack and the time-dilation eclipse attack as “particularly” concerning because a fix would require tinkering with both Lightning Network implementations and Bitcoin Core in tandem.
In pursuit of a fix for the griefing attack, Jager has launched a project for a Lightning client add-on called “circuitbreaker.” The firewall lets nodes set a limit for how many inbound HTLCs they can receive, thereby paralyzing any attacker trying to spam the channel.
circuitbreaker could also be employed to mitigate attack surfaces for flood and loot. But this would also disrupt user experience because it would limit how many HTLCs a user would accept from new nodes on the network.
Simply put, in Jager’s words, “applying limits can have consequences.”
Striking a balance
Just because no one has capitalized on the vulnerabilities for lack of technical chops, that doesn’t guarantee someone won’t try in the future if the network grows. For the network to grow, developers need to make it as user-friendly as possible by tinkering with and adding new features – something that has opened up new attack vectors in the past.
At the heart of the problem, Jager emphasized, is the eternal struggle in software design to balance user-friendliness with robust security (the eclipse attack is a perfect example because it affects Lightning network light clients, which are significantly easier for average users to launch than a full Lightning node).
Instead of preparing for the Earthbound meteor, so to speak, teams are focusing on making their applications easier to use. This is still a laudable goal, but there’s more work to be done behind the scenes on Lightning’s technical guarantees before the protocol can scale to include even more users.
Thankfully, the Lightning Network is still in its infancy so it’s “the perfect time to solve all of these security and hard engineering issues,” Riard said. He’s optimistic for Lightning’s future, but says its proponents need to be realistic about “the full magnitude” of these vulnerabilities if they are to address them.
“Once they’re better understood,” he said, “I’ve no doubt that the wider Bitcoin development community has the talent and patience to address them correctly.”
Jager agrees. In his view, there’s still plenty to be done before Lightning scales to the user base and functionality of something like Venmo. But none of these vulnerabilities compromise the fundamental building blocks of Lightning, nor would he want them to scare anyone away from the network that he sees as Bitcoin’s best bet for scaling.
“There’s still a lot of work to do to make it as easy as a normal payment app. But for me the important thing is, I don’t see fundamental problems for why Lightning wouldn’t work. There’s just a huge amount of work to be done. I think all of these problems will be solved in the end, and there doesn’t seem to be any better alternative to Lightning at the moment.”
