-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
18 changed files
with
375 additions
and
11 deletions.
There are no files selected for viewing
18 changes: 18 additions & 0 deletions
18
...ghtning-dev/Oct_2023/004127_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Batch exchange withdrawal to lightning requires covenants</title> | ||
| <updated>2023-10-19T01:54:44.346158+00:00</updated> | ||
| <author> | ||
| <name>ZmnSCPxj 2023-10-17 17:04:06+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Batch exchange withdrawal to lightning requires covenants</title> | ||
| <updated>2023-10-19T01:54:44.346184+00:00</updated> | ||
| <link href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004127.html" rel="alternate"/> | ||
| <summary>In the email, ZmnSCPxj discusses the risk associated with batched splicing mechanisms in Lightning Network channels. The core of the risk lies in the scenario where there are no funds in a channel and an old state exists. In such cases, if a participant engages in a batched splice, they can disrupt the transaction by broadcasting the old state and convincing miners to confirm it before the batched splice.To mitigate this risk, ZmnSCPxj suggests that any batched splicing mechanism should have a backout option. This means that if the batched splice transaction cannot be confirmed due to a participant posting an old commitment transaction, either a subset of the splice is re-created or the channels revert back to the pre-splice state. It is important to note that the post-splice state cannot be confirmed in this scenario.ZmnSCPxj acknowledges that current splicing technology runs both the pre-splice and post-splice states simultaneously until the splicing transaction is confirmed. However, it is also necessary to check if the splicing transaction cannot be confirmed by verifying if the other inputs to the splice transaction were already consumed by transactions that have deeply confirmed. If this is the case, the post-splice state should be dropped, and the channels should revert to the pre-splice state. It is unclear whether existing splice implementations actually perform this check.In conclusion, ZmnSCPxj highlights the importance of having a backout option in batched splicing mechanisms to address the risk of disruption caused by old commitment transactions. Without such precautions, any form of batched splicing can be risky.</summary> | ||
| <published>2023-10-17T17:04:06+00:00</published> | ||
| </entry> | ||
| </feed> |
18 changes: 18 additions & 0 deletions
18
...ghtning-dev/Oct_2023/004128_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Batch exchange withdrawal to lightning requires covenants</title> | ||
| <updated>2023-10-19T01:54:37.408250+00:00</updated> | ||
| <author> | ||
| <name>Greg Sanders 2023-10-17 17:10:42+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Batch exchange withdrawal to lightning requires covenants</title> | ||
| <updated>2023-10-19T01:54:37.408277+00:00</updated> | ||
| <link href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004128.html" rel="alternate"/> | ||
| <summary>The email discusses the risk associated with batched splicing in splice implementations. It suggests that if a splice implementation decides to splice again when a prior splice isn't confirming, it can lead to potential risks. However, the email also mentions that once any subsequent splice is confirmed, the issue will self-resolve. The author signs off with a farewell message.</summary> | ||
| <published>2023-10-17T17:10:42+00:00</published> | ||
| </entry> | ||
| </feed> |
18 changes: 18 additions & 0 deletions
18
...ghtning-dev/Oct_2023/004129_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Batch exchange withdrawal to lightning requires covenants</title> | ||
| <updated>2023-10-19T01:54:34.188614+00:00</updated> | ||
| <author> | ||
| <name>ZmnSCPxj 2023-10-17 17:17:04+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Batch exchange withdrawal to lightning requires covenants</title> | ||
| <updated>2023-10-19T01:54:34.188642+00:00</updated> | ||
| <link href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004129.html" rel="alternate"/> | ||
| <summary>The email discusses a potential risk related to the "not confirming" status of a splice transaction. It mentions that there is a possibility that the reason for "not confirming" could be due to an unexpected increase in mempool usage. The author highlights an edge case where a previous splice transaction that was not confirming for a while could end up confirming instead of the subsequent splice transaction.This situation could be exploited by attackers, and if implementations naively delete the signatures for commitment transactions for the previously-not-confirming splice transaction, it could result in a loss of funds. The author also points out that part of the splice proposal is that a channel should not be spliced again while it is being spliced, which the recipient's proposal seems to violate.Overall, the email raises concerns about the potential vulnerability and suggests that precautions should be taken to address this risk.Note: The farewell part of the email has been ignored as per the given rules.</summary> | ||
| <published>2023-10-17T17:17:04+00:00</published> | ||
| </entry> | ||
| </feed> |
18 changes: 18 additions & 0 deletions
18
...40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"</title> | ||
| <updated>2023-10-19T01:54:12.892922+00:00</updated> | ||
| <author> | ||
| <name>Antoine Riard 2023-10-17 17:47:14+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"</title> | ||
| <updated>2023-10-19T01:54:12.892955+00:00</updated> | ||
| <link href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004130.html" rel="alternate"/> | ||
| <summary>The email discusses the possibility of a potential attack on Lightning Network (LN) channels and the measures taken to address this issue. The sender clarifies that no such attack has been observed on the mainnet, but there have been discussions and experiments conducted in restricted development circles to test the vulnerability.The attack targets channels with high capacity and loose channel policies. The flow affected is the total value of outbound HTLC (Hashed Time-Locked Contract) in-flight. To monitor the existence of such an attack, one can look at mempool logs and observe the amount of HTLC outputs being conflicted out with a specific sequence.The attack does not resemble a pinning attack, as it does not involve "honest" or "malicious" transactions pinned in network mempools. It can occur without network mempool congestion. The attacker can control two neighboring nodes to target the victim. By cycling the attack on the tail side and delaying the confirmation of the htlc-timeout covenant, the attacker can force-close the channel and claim their timeout-path, canceling back the initial htlc amount to their initial node.The email suggests testing this behavior and mentions that local-mempool preimage monitoring has been implemented by Eclair and LND as a mitigation against old school pinning attacks and replacement cycling attacks, respectively. However, Core-Lightning and LDK have not implemented this mechanism.The email also discusses a defensive fee mitigation strategy proposed in a paper. This strategy involves aggressively fee-bumping the htlc-output and racing it with the preimage claim on the incoming path. It is only feasible with anchor channels where fees can be added to the htlc-covenant. This would make the attack more costly for the peer, especially when fees up to 50% of the htlc value are used.However, the effectiveness of the attack depends on factors such as the amount and number of HTLCs for big channels to unknown peers. It may result in a heavy loss for the attacker when trying to steal small HTLCs.Overall, the email highlights the potential risks associated with certain LN channel configurations and proposes strategies to mitigate these risks.</summary> | ||
| <published>2023-10-17T17:47:14+00:00</published> | ||
| </entry> | ||
| </feed> |
18 changes: 18 additions & 0 deletions
18
...40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"</title> | ||
| <updated>2023-10-19T01:54:03.752789+00:00</updated> | ||
| <author> | ||
| <name>Antoine Riard 2023-10-17 18:34:52+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"</title> | ||
| <updated>2023-10-19T01:54:03.752824+00:00</updated> | ||
| <link href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004131.html" rel="alternate"/> | ||
| <summary>In the email, the sender discusses a scenario involving channels and transactions in the context of Bitcoin programming. The sender mentions that without 'C' claiming it, 'B' forces the 'B====C' channel onchain. They explain that HTLC-timeout transactions do not confirm because they are replaced by C's HTLC-preimage, which remains valid after the HTLC timelock between 'B' and 'C' expires. This HTLC-preimage is then replaced itself.The sender provides a test link (https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf) to support their explanation. They mention that 'A' drops the 'A====B' channel onchain and tries to recover the HTLC funds. They clarify that considering the fee rates and mempool congestion is unnecessary as the exploit lies in the replacement mechanism itself.The email also discusses low feerates and how CPFPs (Child Pays For Parent) the commitment transaction. It mentions that 'C' can use the knowledge of the preimage, as its own incoming HTLC has already been confirmed as claimed by 'A'. The sender explains that 'C' broadcasts an HTLC-success transaction at block height 144, but does so at every block between blocks 100 and 144 to replace 'B's HTLC-timeout transaction. They note that 'B' cannot feebump this transaction since it is presigned in this case, and they explain why 'B' cannot feebump it using the sighash_single | anyonecanpay on 'C's signature.</summary> | ||
| <published>2023-10-17T18:34:52+00:00</published> | ||
| </entry> | ||
| </feed> |
18 changes: 18 additions & 0 deletions
18
...40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"</title> | ||
| <updated>2023-10-19T01:53:57.129526+00:00</updated> | ||
| <author> | ||
| <name>Antoine Riard 2023-10-17 18:47:59+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"</title> | ||
| <updated>2023-10-19T01:53:57.129561+00:00</updated> | ||
| <link href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004132.html" rel="alternate"/> | ||
| <summary>In a recent email, the sender acknowledges a previous discussion regarding conducting experiments pre-disclosure. They express their willingness to set up a "black box" Lightning infrastructure on mainnet in order to exercise vulnerabilities and mitigations. The sender suggests that the disclosure date could be adjusted based on the learnings from these experiments. However, due to the limited number of Lightning experts with the necessary knowledge and understanding to participate in the experiments, and the existence of other pending non-disclosed security issues, the experiments were not conducted. Specifically, the sender mentions the "fake channel DoS vector" issue revealed on August 23, 2023.</summary> | ||
| <published>2023-10-17T18:47:59+00:00</published> | ||
| </entry> | ||
| </feed> |
18 changes: 18 additions & 0 deletions
18
...ghtning-dev/Oct_2023/004133_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Batch exchange withdrawal to lightning requires covenants</title> | ||
| <updated>2023-10-19T01:54:29.378100+00:00</updated> | ||
| <author> | ||
| <name>Antoine Riard 2023-10-17 19:10:40+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Batch exchange withdrawal to lightning requires covenants</title> | ||
| <updated>2023-10-19T01:54:29.378133+00:00</updated> | ||
| <link href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004133.html" rel="alternate"/> | ||
| <summary>Antoine is expressing uncertainty about the robustness of secure fee-bumping, even with future mechanisms like package relay and nversion=3, for multi-party transactions and covenant-enable constructions under usual risk models. Antoine provides a link to a test on GitHub for reference. Antoine is seeking the input of experts who understand both lightning and core mempool on this matter. There has been a lot of discussion regarding the design rules of nversion=3, and the test is typically based on the glozow top commit of October 3, 2023. Antoine concludes the email with a farewell.</summary> | ||
| <published>2023-10-17T19:10:40+00:00</published> | ||
| </entry> | ||
| </feed> |
18 changes: 18 additions & 0 deletions
18
...40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"</title> | ||
| <updated>2023-10-19T01:53:53.161794+00:00</updated> | ||
| <author> | ||
| <name>Matt Corallo 2023-10-18 00:17:44+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"</title> | ||
| <updated>2023-10-19T01:53:53.161831+00:00</updated> | ||
| <link href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004134.html" rel="alternate"/> | ||
| <summary>There is confusion surrounding the issue at hand and the proposed mitigations. It is important to note that the deployed mitigations are not expected to fully resolve the issue, and some argue that they serve more as a PR statement. Two mitigations have been discussed: mempool scanning and transaction re-signing/re-broadcasting.Mempool scanning involves regularly checking the mempool of a local node to detect if the replacement cycle is happening. However, this method only works if the first transaction is seen before it is replaced by the second transaction. Currently, most lightning nodes run on machines with a Bitcoin node on the same IP address, making it easy for an attacker to connect to the local node and quickly perform the replacement without the victim noticing. This discoverability is also true for mining pools, which means an attacker can target a miner's node directly, limiting the reach of the intermediate transaction to only miners and preventing the victim from discovering it.The second mitigation, re-signing and re-broadcasting the victim's transaction, may work if the attacker is lazy and has not completed their attack system. However, if the attacker has control over a large majority of the hashrate, they can aggressively cycle through replacements, significantly reducing the likelihood of the victim's transaction being confirmed.It is worth mentioning that the above scenarios assume an ideal network environment. The P2P network has its share of slow nodes and unpredictable behavior, so there is a small possibility that these mitigations could accidentally prevent an attack due to timing or other factors. However, this is far from being a comprehensive solution.Ultimately, the only effective fix for this issue would be if miners keep a history of transactions they have seen and attempt to include them in the mempool after a potential attack like this has occurred. This approach would require miners to re-evaluate transactions that were initially excluded due to the attack. Please note that the farewell part of the email has been excluded from this summary.</summary> | ||
| <published>2023-10-18T00:17:44+00:00</published> | ||
| </entry> | ||
| </feed> |
18 changes: 18 additions & 0 deletions
18
...40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"</title> | ||
| <updated>2023-10-19T01:53:45.105254+00:00</updated> | ||
| <author> | ||
| <name>Antoine Riard 2023-10-18 02:57:34+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"</title> | ||
| <updated>2023-10-19T01:53:45.105295+00:00</updated> | ||
| <link href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004135.html" rel="alternate"/> | ||
| <summary>The email discusses various mitigations for lightning attacks in the context of disclosure mails. One of the mitigations mentioned is bumping CLTV delta, which allows node operators to intervene and re-broadcast their time-sensitive transactions on other interfaces if the first one is eclipsed. Another mitigation mentioned is transaction re-signing, which seems to impose an economic cost on the attack in terms of fees or feerates.The effectiveness of this cost in deterring attacks is uncertain, and it is unclear if the game theory behind it holds. The deployment of stratum v2 is suggested as a potential way to make the attack harder, as it increases the number of miners with their own block templates and mempools that the attacker would need to continuously replace channels counterparties transactions in cycles.A possible mitigation that could be explored is the use of a replacement buffer or history of transactions at the mempool level. It is mentioned that individuals like Tadge and Rusty, who were involved in the early design of lightning, might have additional ideas for mitigations. The issue of fees is highlighted as a challenging aspect in the original paper.Overall, the email raises interesting points about different mitigations for lightning attacks and suggests further exploration and discussion on the topic.</summary> | ||
| <published>2023-10-18T02:57:34+00:00</published> | ||
| </entry> | ||
| </feed> |
Oops, something went wrong.