This is the first article in our two-part series on existing vulnerabilities in Bitcoin’s Lightning Network. The first part details the exceptional vulnerabilities and their risk factors. Part two will examine why these weak spots have never been exploited, what changes can be made to correct them, and the developing trade-offs that arise from balancing user-friendly applications and tight security.
A common joke (or perhaps an admission) in Bitcoin circles claims that Bitcoin’s most loyal supporters are also its harshest critics, especially those from its developer circle. They know how the sausage is made, so to speak, and can see the unsavory side of how bits and bytes are handled with each new update.
It’s not that these developers are negative towards Bitcoin; they are just realistic.
This could certainly be said about Antoine Riard. The developer at Chaincode Labs is the author of several articles this year on attack vectors for the Lightning Network. He mentions these vulnerabilities (and others) in a new blog post, “Why We May Fail Lightning” as a sobering reminder that despite the hype, Bitcoin’s secondary network for faster and less payments Dear ones still need work before they can withstand a mass deployment.
And he’s not the only Lightning developer to have this opinion.
In the words of independent Lightning developer Joost Jager, at the heart of these attack vectors are design tradeoffs that expose “the balance between build functionality and build functionality. [Lightning] secures. ”Some features like Neutrino, for example, which opened the door to more reliable and more light-friendly mobile wallets, have also opened up new types of attacks.
Read more: What is Bitcoin Lightning Network?
Each upgrade provides an opportunity to both improve the protocol and exploit the new problems created by the new solutions.
“Lightning is great, but I can’t say he’s been battle tested. If script kids were interested, they could remove these 5 shiny new wumbo BTC channels with negligible cost and effortlessly at all, ”said Joost Jager, a Lightning Network Engineer who previously worked at Lightning Labs. tweeted.
The following is a list of some of the more disturbing attacks that could be launched on Bitcoin’s Lightning Network.
Vulnerability: mourning
Jager’s discussion thread details a so-called “painful” attack that has been possible since Lightning’s inception and affects normal and newly deployed wumbo channels.
Lightning channels execute payments over the network using a cryptographic feature called hash-time-lock (HTLC) contracts. Lightning channels can only accommodate a few hundred HTLCs. Once this reaches the maximum, the channel can no longer process payments – funds would be blocked and the channel must be closed.
How grief can cause problems
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 funds from another user, it could be used by an adversary to sabotage a competitor’s ability to route payments, Jager said.
Consequences: minimal
Compared to other vulnerabilities in Lightning Network, grief is low on the danger scale because it can only freeze funds, not steal them. However, in theory, the attack could be used by Lightning Service Providers (LSPs), the Lightning-based companies that handle most of the network’s liquidity, to sabotage a competitor’s business.
For wumbo chains, this is of particular concern given that the attack could cost a few pennies to execute while also disabling chains with a lot of bitcoin locked. An attacker could also jam multiple channels with this technique if payments are also routed, Jager told CoinDesk.
What are developers doing to fix it?
Since this attack isn’t the most serious, Lightning makers never pushed much to address it. Jager, however, is in the process of drafting a firewall solution called a “circuitbreaker” so that node operators can set limits on the number of payments and channels a peer can open with their node.
Vulnerability: flood and loot
Flood and loot is similar to the painful attack Jager mentioned in that it requires spamming a payment channel. In this case, however, the funds are in fact put at risk.
How flooding and looting can cause problems
Essentially, an attacker would open channels with a victim (or multiple victims) and then send payments to another node they control without confirming that the payments have been received. Each of these channels is coded to close at the same time.
When this happens, it’s inevitable that a handful of those closing transactions will fail because there are so many streaming to the Bitcoin blockchain at the same time (when a Lightning payment channel is closed, its funds are sent to Bitcoin addresses chain). While some of these transactions are waiting to be confirmed, the attacker can broadcast their own transactions on the blockchain with higher fees 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 into solving the problem.
Consequences: moderate to severe
Floods and looting are more serious than painful attack as a victim may actually lose funds due to this vulnerability. It’s easier to execute than the other vulnerabilities in this article, but it would still take a solid understanding of Lightning to be successful.
What are developers doing to fix it?
The recently released Anchor Channels update, which allows Lightning users to change charges more dynamically when a channel is closed, will go a long way in addressing this vulnerability.
Vulnerability: time dilation eclipse
There are other more complex attacks such as the time dilation attack that Riard revealed to 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 serve thin clients (that is, Lightning wallets that run with the bare minimum of data needed to function).
How an eclipse attack could cause problems
If an attacker were to run hundreds of nodes and clog all connections of an entire Lightning node so that the victim was no longer connected to honest users, the attacker can isolate that node from receiving network data. real.
With node connections “eclipsed”, the attacker can feed the node’s transaction data at a slower rate than normal. Once the attacker closes their Lightning channels with the victim, he or she could steal funds on that channel as their host node will not see the channel close transaction on the blockchain because they are not receiving the data quickly enough.
Consequences: serious
The attack is particularly threatening against thin clients because these Lightning wallets only receive blockchain data one block at a time, as opposed to a full Lightning client who always has a copy of the blockchain transaction history. .
Thin clients comprise the bulk of mainstream Lightning Network wallets from a handful of vendors such as Lightning Labs, Phoenix, Blue Wallet, and other Lightning service providers. When they wrote the article in June 2020, Riard and Naumenko estimated that a successful large-scale attack could eclipse 47% of newly deployed thin clients.
The attack is serious in that a victim could lose funds. That said, the attack requires the malicious actor to operate – and coordinate – hundreds of nodes to successfully eclipse a victim. It can certainly be accomplished, but it would take a very skilled hacker with a keen eye for Bitcoin and the Lightning Network.
What are developers doing to fix it?
This attack is trickier than the others in a way because there is no single solution you can deploy over the Lightning protocol; Because this attack also relies on on-chain data manipulation, it also requires coordination with development on the Bitcoin blockchain to find a sustainable solution.
Vulnerability: pinning
Another attack that requires incongruous transaction data is known as a “pinning attack”.
How pinning can cause problems
To exploit this vulnerability, a sophisticated attacker blocks a channel shutdown transaction by broadcasting conflicting transactions to separate nodes with different mempools. (Remember: there is no uniform pool for pending transactions on Bitcoin’s network; some nodes receive transactions, others are not based on the distribution of peer-to-peer network connections, so each mempool is different).
By using a variety of techniques, one of which is to set a fee low enough on a closing transaction to ensure that it is not confirmed before the channel expires, an attacker can trick a victim into causing it to shut down its channels incorrectly, thus stealing individual transactions. .
Consequences: moderate
Funds can be stolen using this attack, but as we warned with the Eclipse and the Flood and Loot, it also requires impressive technical knowledge on the attacker’s part.
What are developers doing to fix it?
In part, updating anchor outputs will help mitigate this attack vector. But as with the eclipse attack, this attack relies on coordination with the Bitcoin blockchain, so a solution will have to take into account both networks.
Not so scary – yet
Some of these vulnerabilities are more doable (and expensive) than others, but the good news is, no one has ever exploited them. We’ll discuss why this is part of Part 2 of this series, and outline some of the fixes that are ongoing.
Additionally, Riard and Jager will share their thoughts on the future of the Lightning Network and the delicate balance developers need to strike between user experience and security when building the protocol.
Coming Tomorrow: Lightning Network Attack Vectors Never Hit – Some Pressure Can Help Network