Lightning Channel Penalty Enforced
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!
A lightning payment channel keeps track of the current state between two parties. The lightning network has protections in place to enforce a penalty against nodes which attack the network by broadcasting old copies of the state in an attempt to close the transaction. In this case, it appears that the action was not malicious. Only a small quantity of funds were lost due to the incident.
This is a global/international case not involving a specific country.[1][2][3][4][5][6][7]
About Bitcoin
"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."
"Lightning DOSers seem organized and motivated, developing specialized software to attack the Beta LND nodes. Node hardening is in progress! We're getting a good opportunity to develop robust p2p deployment strategies. @juscamarena just saw a live test of the penalty scenario."
As u/chrisrico explained: “FYI this wasn’t a hacker, but a user on the LND slack who had a corrupted channel database, restored an old backup, then closed his channels. Because the backup was out of date, his node broadcast old channel states and his channel partners’ nodes detected this as fraud and published the penalty transactions.”
"So no hacker was apparently involved, though the responsible user did lose the 0.00299095 BTC they had originally deposited into the channel for their starter balance."
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.
| Date | Event | Description |
|---|---|---|
| March 25th, 2018 6:40:00 PM MDT | Main Event | Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here. |
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.
References
- ↑ ⚡ Hackers tried to steal funds from a Lightning channel, just to end up losing theirs as the penalty system worked as expected : Bitcoin (Feb 17, 2022)
- ↑ @alexbosworth Twitter (Feb 17, 2022)
- ↑ Lightning Network 'Penalty Scenario' Works in Old State Channel Incident (Feb 21, 2022)
- ↑ New Record For Bitcoin Lightning Network As Adoption Grows (Feb 21, 2022)
- ↑ Lightning Network (Feb 21, 2022)
- ↑ Lightning Network - Wikipedia (Feb 21, 2022)
- ↑ https://lightning.network/lightning-network-summary.pdf (Apr 9, 2022)