Lightning Denial of Service Attack Demonstration

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' section to other sections, and add any missing information or sources you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

Lightning

Lightning is a technology which allows for faster and cheaper payments through bitcoin. In Septembr 2020, Joost Jager discovered an attack which could be performed against large value lightning channels. This allowed nodes to be locked up so they're unusable, but doesn't appear to allow any theft of funds.

This is a global/international case not involving a specific country.

About Lightning

"The Lightning Network (LN) is a "layer 2" payment protocol layered on top of a blockchain-based cryptocurrency such as bitcoin or litecoin. It is intended to enable fast transactions among participating nodes and has been proposed as a solution to the bitcoin scalability problem. It features a peer-to-peer system for making micropayments of cryptocurrency through a network of bidirectional payment channels without delegating custody of funds."

"Normal use of the Lightning Network consists of opening a payment channel by committing a funding transaction to the relevant base blockchain (layer 1), followed by making any number of Lightning Network transactions that update the tentative distribution of the channel's funds without broadcasting those to the blockchain, optionally followed by closing the payment channel by broadcasting the final version of the settlement transaction to distribute the channel's funds."

"To settle the payments the channel must be closed. To initiate this process one node broadcasts the most up to date settlement transaction to the network. The next events can broadly be thought of in two ways, a cooperative closure in which both parties confirm a distribution and funds are immediately settled and an uncooperative closure. Uncooperative closes may be legitimate for example if one node is no longer part of the network or fraudulent with one node broadcasting an incorrect distribution (likely an outdated one). In uncooperative closures the funds are not settled instantly but there is a dispute period within which nodes may contest the broadcast distribution. If the second node broadcasts a more up to date distribution then the funds are transferred entirely to them. This punitive act, known as the breach remedy transaction, prevents nodes from attempting to defraud the network by broadcasting out-of-date transactions."

"Lightning-fast blockchain payments without worrying about block confirmation times. Security is enforced by blockchain smart-contracts without creating a on-blockchain transaction for individual payments. Payment speed measured in milliseconds to seconds." "Capable of millions to billions of transactions per second across the network. Capacity blows away legacy payment rails by many orders of magnitude. Attaching payment per action/click is now possible without custodians." "By transacting and settling off-blockchain, the Lightning Network allows for exceptionally low fees, which allows for emerging use cases such as instant micropayments." "Cross-chain atomic swaps can occur off-chain instantly with heterogeneous blockchain consensus rules. So long as the chains can support the same cryptographic hash function, it is possible to make transactions across blockchains without trust in 3rd party custodians."

"A wumbo channel removes the limit to the total amount of Bitcoin that can be held in a regular Lightning channel — which is around $1,760 worth at today’s prices. It also removes the approx. $450 limit to how large an individual payment can be."

"The word “wumbo” comes from a cartoon series called SpongeBob SquarePants, and refers to the idea that two parties need to agree to ‘wumbo’ together for the transaction to take place."

"In today's Lighting Network payments are routed via a series of hops. Each of those hops will incur a cost for forwarding that payment. While the htlc of an hop is in-flight, the associated amount is locked in the hop's outgoing channel. Those funds cannot be used for another purpose. This can be considered to be an opportunity cost."

"Furthermore each channel has a limited number of htlc 'slots'. The current maximum is 483 slots. This means that regardless of channel capacity, there can never be more than 483 htlcs pending. With large channels in particular, it can happen that all slots are occupied while only a fraction of the channel capacity is used. In that case the whole channel is considered to be locked. The duration of the lock can vary from a few seconds to as long as 2 weeks or even more."

"When the payment is completed successfully, each hop will collect a routing fee. But depending on the length of the lock and the htlc amounts, this may be far from sufficient to cover the costs."

"Various cybersecurity vulnerabilities are entirely unique to Lightning." "Independent Bitcoin Lightning developer, Joost Jager, has outlined an exploit of the micro-payments network that could result in channels being compromised with very little effort and negligible cost."

"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."

"The most famous, described by developer Joost Jager, demonstrated that the Lightning Network is vulnerable to denial-of-service attacks."

"Jager said the wumbo channels can be exploited because the channel cannot hold more than 483 hash and time-lock contracts (HTLCs) at any time regardless of its capacity. So a malicious actor sending 483 micro-payments to themselves, and holding on to the HTLCs is enough to incapacitate a channel for up to two weeks."

"An attacker could fill channels to maximum capacity for hash-time-lock contracts (HTLCs)." "The underlying issue is that a channel cannot hold more than 483 htlcs at a time, regardless of the channel capacity. Sending 483 micro-payments to yourself and holding on to the htlcs is enough to incapacitate a channel for up to two weeks."

"This attack would force a Lightning user to close the channel because the funds would be “stuck.”" "By utilizing the max route length to add loops, each payment can consume up to 9 htlc slots on the target channel. If the script kid is lucky, they only need to send 54 payments to get it done. A single tiny channel takes double-digit amounts of #bitcoin out of business."

"Attackers could use this griefing attack to sabotage someone else’s transaction, even if they cannot directly steal the funds."

"Attackers could also compromise a user through an eclipse attack, which uses hundreds of fraudulent (non-routing, uncooperative) nodes to make it difficult for a victim to find a legitimate node through which to send transaction data."

"Here you see me locking up ~5800000 sat with a refundable 18 sat payment looping five times through three mainnet channels owned by @bitfinex and @OpenNodeCo. For basically as long as I want. This happened today."

"Wanting to become the world's payment system sounds good, but then we can't have trivially exploitable vulnerabilities like this. Walk the talk."

Joost Jager apparently "started a new project called Circuit Breaker: a firewall for Lightning nodes. The primary goal is to encourage thinking about this problem, with the potential to grow into a full-fledged Lightning protection system."

"It allows nodes to protect themselves from being flooded with htlcs. With circuitbreaker a maximum to the number of in-flight htlcs can be set on a per-peer basis. Known and trusted peers for example can be assigned a higher maximum, while a new channel from a previously unseen node may be limited to only a few pending htlcs."

"Furthermore it is possible to apply rate limits to the number of forwarded htlcs. This offers protection against DoS/spam attacks that rely on large numbers of fast-resolving htlcs. Rate limiting is implemented with a Token bucket. In configuration the minimum interval between htlcs and a burst size can be specified."

This is a global/international case not involving a specific country.

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - Lightning Denial of Service Attack Demonstration

Date	Event	Description
September 22nd, 2020 8:34:00 AM MDT	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.

Technical Details

This section includes specific detailed technical analysis of any security breaches which happened. What specific software vulnerabilities contributed to the problem and how were they exploited?

Total Amount Lost

No funds were lost.

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

Total Amount Recovered

There do not appear to have been any funds recovered in this case.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

What parts of this case are still remaining to be concluded?

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.