From ee72f73c5002509487424f42dbb8683a01b4473b Mon Sep 17 00:00:00 2001 From: urvishp80 Date: Thu, 19 Oct 2023 01:55:30 +0000 Subject: [PATCH] Updated newly generated xml files --- ...drawal-to-lightning-requires-covenants.xml | 18 ++++++++ ...drawal-to-lightning-requires-covenants.xml | 18 ++++++++ ...drawal-to-lightning-requires-covenants.xml | 18 ++++++++ ...234-All-your-mempool-are-belong-to-us-.xml | 18 ++++++++ ...234-All-your-mempool-are-belong-to-us-.xml | 18 ++++++++ ...234-All-your-mempool-are-belong-to-us-.xml | 18 ++++++++ ...drawal-to-lightning-requires-covenants.xml | 18 ++++++++ ...234-All-your-mempool-are-belong-to-us-.xml | 18 ++++++++ ...234-All-your-mempool-are-belong-to-us-.xml | 18 ++++++++ ...hannel-reserve-for-mobile-wallet-users.xml | 18 ++++++++ ...hannel-reserve-for-mobile-wallet-users.xml | 18 ++++++++ ...drawal-to-lightning-requires-covenants.xml | 18 ++++++++ ...hannel-reserve-for-mobile-wallet-users.xml | 18 ++++++++ ...hannel-reserve-for-mobile-wallet-users.xml | 18 ++++++++ ...hannel-reserve-for-mobile-wallet-users.xml | 18 ++++++++ ...drawal-to-lightning-requires-covenants.xml | 39 +++++++++++++++++ ...234-All-your-mempool-are-belong-to-us-.xml | 42 ++++++++++++++----- ...hannel-reserve-for-mobile-wallet-users.xml | 35 ++++++++++++++++ 18 files changed, 375 insertions(+), 11 deletions(-) create mode 100644 static/lightning-dev/Oct_2023/004127_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml create mode 100644 static/lightning-dev/Oct_2023/004128_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml create mode 100644 static/lightning-dev/Oct_2023/004129_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml create mode 100644 static/lightning-dev/Oct_2023/004130_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml create mode 100644 static/lightning-dev/Oct_2023/004131_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml create mode 100644 static/lightning-dev/Oct_2023/004132_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml create mode 100644 static/lightning-dev/Oct_2023/004133_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml create mode 100644 static/lightning-dev/Oct_2023/004134_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml create mode 100644 static/lightning-dev/Oct_2023/004135_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml create mode 100644 static/lightning-dev/Oct_2023/004136_Removing-channel-reserve-for-mobile-wallet-users.xml create mode 100644 static/lightning-dev/Oct_2023/004137_Removing-channel-reserve-for-mobile-wallet-users.xml create mode 100644 static/lightning-dev/Oct_2023/004138_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml create mode 100644 static/lightning-dev/Oct_2023/004139_Removing-channel-reserve-for-mobile-wallet-users.xml create mode 100644 static/lightning-dev/Oct_2023/004140_Removing-channel-reserve-for-mobile-wallet-users.xml create mode 100644 static/lightning-dev/Oct_2023/004141_Removing-channel-reserve-for-mobile-wallet-users.xml create mode 100644 static/lightning-dev/Oct_2023/combined_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml create mode 100644 static/lightning-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml diff --git a/static/lightning-dev/Oct_2023/004127_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml b/static/lightning-dev/Oct_2023/004127_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml new file mode 100644 index 000000000..465c6e53f --- /dev/null +++ b/static/lightning-dev/Oct_2023/004127_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml @@ -0,0 +1,18 @@ + + + 1 + Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:44.346158+00:00 + + ZmnSCPxj 2023-10-17 17:04:06+00:00 + + python-feedgen + + 1 + Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:44.346184+00:00 + + 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. + 2023-10-17T17:04:06+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004128_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml b/static/lightning-dev/Oct_2023/004128_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml new file mode 100644 index 000000000..e84e5a7b7 --- /dev/null +++ b/static/lightning-dev/Oct_2023/004128_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml @@ -0,0 +1,18 @@ + + + 1 + Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:37.408250+00:00 + + Greg Sanders 2023-10-17 17:10:42+00:00 + + python-feedgen + + 1 + Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:37.408277+00:00 + + 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. + 2023-10-17T17:10:42+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004129_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml b/static/lightning-dev/Oct_2023/004129_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml new file mode 100644 index 000000000..4937baa2b --- /dev/null +++ b/static/lightning-dev/Oct_2023/004129_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml @@ -0,0 +1,18 @@ + + + 1 + Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:34.188614+00:00 + + ZmnSCPxj 2023-10-17 17:17:04+00:00 + + python-feedgen + + 1 + Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:34.188642+00:00 + + 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. + 2023-10-17T17:17:04+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004130_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml b/static/lightning-dev/Oct_2023/004130_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml new file mode 100644 index 000000000..7c9168046 --- /dev/null +++ b/static/lightning-dev/Oct_2023/004130_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml @@ -0,0 +1,18 @@ + + + 1 + Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:54:12.892922+00:00 + + Antoine Riard 2023-10-17 17:47:14+00:00 + + python-feedgen + + 1 + Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:54:12.892955+00:00 + + 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. + 2023-10-17T17:47:14+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004131_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml b/static/lightning-dev/Oct_2023/004131_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml new file mode 100644 index 000000000..4922dbd11 --- /dev/null +++ b/static/lightning-dev/Oct_2023/004131_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml @@ -0,0 +1,18 @@ + + + 1 + Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:54:03.752789+00:00 + + Antoine Riard 2023-10-17 18:34:52+00:00 + + python-feedgen + + 1 + Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:54:03.752824+00:00 + + 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. + 2023-10-17T18:34:52+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004132_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml b/static/lightning-dev/Oct_2023/004132_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml new file mode 100644 index 000000000..fc6a2fec6 --- /dev/null +++ b/static/lightning-dev/Oct_2023/004132_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml @@ -0,0 +1,18 @@ + + + 1 + Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:53:57.129526+00:00 + + Antoine Riard 2023-10-17 18:47:59+00:00 + + python-feedgen + + 1 + Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:53:57.129561+00:00 + + 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. + 2023-10-17T18:47:59+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004133_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml b/static/lightning-dev/Oct_2023/004133_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml new file mode 100644 index 000000000..17ba4a433 --- /dev/null +++ b/static/lightning-dev/Oct_2023/004133_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml @@ -0,0 +1,18 @@ + + + 1 + Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:29.378100+00:00 + + Antoine Riard 2023-10-17 19:10:40+00:00 + + python-feedgen + + 1 + Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:29.378133+00:00 + + 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. + 2023-10-17T19:10:40+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004134_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml b/static/lightning-dev/Oct_2023/004134_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml new file mode 100644 index 000000000..232d908c2 --- /dev/null +++ b/static/lightning-dev/Oct_2023/004134_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml @@ -0,0 +1,18 @@ + + + 1 + Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:53:53.161794+00:00 + + Matt Corallo 2023-10-18 00:17:44+00:00 + + python-feedgen + + 1 + Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:53:53.161831+00:00 + + 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. + 2023-10-18T00:17:44+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004135_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml b/static/lightning-dev/Oct_2023/004135_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml new file mode 100644 index 000000000..ec059205f --- /dev/null +++ b/static/lightning-dev/Oct_2023/004135_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml @@ -0,0 +1,18 @@ + + + 1 + Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:53:45.105254+00:00 + + Antoine Riard 2023-10-18 02:57:34+00:00 + + python-feedgen + + 1 + Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:53:45.105295+00:00 + + 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. + 2023-10-18T02:57:34+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004136_Removing-channel-reserve-for-mobile-wallet-users.xml b/static/lightning-dev/Oct_2023/004136_Removing-channel-reserve-for-mobile-wallet-users.xml new file mode 100644 index 000000000..b50756da5 --- /dev/null +++ b/static/lightning-dev/Oct_2023/004136_Removing-channel-reserve-for-mobile-wallet-users.xml @@ -0,0 +1,18 @@ + + + 1 + Removing channel reserve for mobile wallet users + 2023-10-19T01:55:22.848304+00:00 + + Bastien TEINTURIER 2023-10-18 13:51:11+00:00 + + python-feedgen + + 1 + Removing channel reserve for mobile wallet users + 2023-10-19T01:55:22.848329+00:00 + + The email discusses the idea of getting rid of the channel reserve requirement for channels between mobile wallet users and their service providers. The channel reserve requirement ensures that both peers always have an output in the commit transaction, which has two important consequences. First, if a malicious node publishes a revoked commitment, they will risk losing money because the honest node can claim the funds. Second, nodes are disincentivized from force-closing channels because they would need to pay on-chain fees to get their funds back.The author believes that these properties are important for channels between normal routing nodes that don't provide paid services to each other. However, there are drawbacks to having a channel reserve. One drawback is capital efficiency because the reserve represents unused liquidity. For routing nodes, this may not be an issue as they actively manage their channels. But for wallet providers, who need to keep at least one channel open with each user, it becomes a scalability problem.Another drawback is the user experience (UX). Users look at their channel state to determine how much they can receive off-chain. It becomes difficult to explain why there is a large gap between what they think they should be able to receive and what they actually can receive.In the specific setting of channels between mobile wallet users and their service providers, the author argues that it is acceptable to remove the channel reserve on both sides. The service provider pays the on-chain fees for the commit transaction, even if they don't have an output in the transaction. This means they still lose something if they publish a revoked commit transaction. The wallet user can still get their funds back using penalty transactions, which doesn't cost them more than normal second-stage transactions. The service provider cannot steal funds but can grief their users, at the cost of paying on-chain fees and missing out on future routing fees. The wallet user can publicly show that the service provider published a revoked commitment, which can damage their reputation.Removing the reserve on the wallet user's side is a risk that the wallet provider takes to ensure a good user experience. The griefing amount is limited, and the user has already paid fees to the wallet provider before reaching that state. This trade-off is considered acceptable for service providers. Additionally, it can be argued that LN-penalty without channel reserves is similar to LN-symmetry (Eltoo), where a cheating node can always publish a previous commitment, and the honest node can replay the latest state on top of that commitment. In this case, when the service provider tries to cheat, they pay the on-chain fees for the commit transaction, similar to Eltoo.Overall, the email presents an argument for removing the channel reserve requirement for channels between mobile wallet users and their service providers, highlighting the benefits and addressing potential concerns. + 2023-10-18T13:51:11+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004137_Removing-channel-reserve-for-mobile-wallet-users.xml b/static/lightning-dev/Oct_2023/004137_Removing-channel-reserve-for-mobile-wallet-users.xml new file mode 100644 index 000000000..1e8a13bc8 --- /dev/null +++ b/static/lightning-dev/Oct_2023/004137_Removing-channel-reserve-for-mobile-wallet-users.xml @@ -0,0 +1,18 @@ + + + 1 + Removing channel reserve for mobile wallet users + 2023-10-19T01:55:12.684412+00:00 + + Tony Giorgio 2023-10-18 14:33:36+00:00 + + python-feedgen + + 1 + Removing channel reserve for mobile wallet users + 2023-10-19T01:55:12.684438+00:00 + + In the email, Tony Giorgio acknowledges Bastien's previous message but raises some questions and clarifications regarding the proposed user experience (UX) for wallets and Lightning Service Providers (LSPs). Tony asks if the proposal suggests a network-wide switch away from reserves or only applies to mobile wallets and LSPs that choose to opt in. Additionally, he inquires about the dust reserve limit.Tony notes that wallets and LSPs already offer the option to provide this UX and have been doing so for years. He seeks clarification on whether the proposal aims to replace reserves entirely or if it is specific to certain types of wallets and LSPs.Moreover, Tony mentions the dust reserve limit and expresses his understanding that all node implementations currently allow for the removal of the 1% reserve requirement while still maintaining the dust reserve. However, he seeks further information or clarification on this matter.The email concludes with Tony's name and the message being forwarded. + 2023-10-18T14:33:36+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004138_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml b/static/lightning-dev/Oct_2023/004138_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml new file mode 100644 index 000000000..b1a6fb2e5 --- /dev/null +++ b/static/lightning-dev/Oct_2023/004138_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml @@ -0,0 +1,18 @@ + + + 1 + Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:25.556872+00:00 + + Bastien TEINTURIER 2023-10-18 14:35:40+00:00 + + python-feedgen + + 1 + Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:25.556904+00:00 + + In the email, there is a discussion about batched splices and their use of 0-conf transactions. It is mentioned that batched splices cannot use 0-conf and that the transaction must be confirmed to remove the risk of double spends. The writer also mentions a drafted protocol where the LSP can finalize and broadcast the batched splice transaction while users are offline, making it feel like a 0-conf transaction when users reconnect. The email also brings up the need for a mechanism to detect double-spent splice transactions, noting that this is not specific to batched transactions but also applies to 2-party splice transactions. The spec does not have a way to abort a splice after exchanging signatures, but it can be done as an RBF operation. The writer agrees with this approach and mentions that a channel being spliced can be spliced again as an RBF attempt, which double spends the other unconfirmed splice attempts.There is some confusion in the email about the use of RBF on batched transactions compared to non-multi-party transactions. The writer argues that using RBF on batched transactions may not be possible and suggests relying on CPFP and potentially package relay instead. They provide a link to a commit on GitHub for further reference.Additionally, the writer mentions that the protocol being discussed is different from the standard replacement cycling attack because wallet users can only unilaterally double-spend with a commit tx, on which they cannot set the feerate. The only participant that can easily double-spend is the exchange, but they wouldn't have an incentive to do so in this case since users are only withdrawing funds.Overall, the email covers various topics related to batched splices, including the use of 0-conf transactions, mechanisms for detecting double-spent transactions, the possibility of using RBF, and the differences between the discussed protocol and the standard replacement cycling attack. + 2023-10-18T14:35:40+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004139_Removing-channel-reserve-for-mobile-wallet-users.xml b/static/lightning-dev/Oct_2023/004139_Removing-channel-reserve-for-mobile-wallet-users.xml new file mode 100644 index 000000000..bde630ae5 --- /dev/null +++ b/static/lightning-dev/Oct_2023/004139_Removing-channel-reserve-for-mobile-wallet-users.xml @@ -0,0 +1,18 @@ + + + 1 + Removing channel reserve for mobile wallet users + 2023-10-19T01:55:07.438603+00:00 + + Bastien TEINTURIER 2023-10-18 14:47:00+00:00 + + python-feedgen + + 1 + Removing channel reserve for mobile wallet users + 2023-10-19T01:55:07.438629+00:00 + + In the email, Bastien is discussing the current state of wallets in Phoenix and proposing a change to the reserve requirements for Lightning Service Providers (LSPs). He mentions that currently, wallet users are allowed to have no reserve, but LSPs must meet the usual reserve requirements.Bastien's goal is to argue that the requirement for LSPs to have a reserve should also be removed without compromising trust. He believes that the channel reserve is necessary between routing nodes because they do not have a "service provider" relationship, which creates more incentive to cheat. However, he argues for removing the reserve requirement between wallet users and their LSPs, as LSPs are not anonymous nodes and care about their reputation.The email ends with a question from Bastien, asking Tony to clarify what he means by the "dust reserve limit." + 2023-10-18T14:47:00+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004140_Removing-channel-reserve-for-mobile-wallet-users.xml b/static/lightning-dev/Oct_2023/004140_Removing-channel-reserve-for-mobile-wallet-users.xml new file mode 100644 index 000000000..3104af889 --- /dev/null +++ b/static/lightning-dev/Oct_2023/004140_Removing-channel-reserve-for-mobile-wallet-users.xml @@ -0,0 +1,18 @@ + + + 1 + Removing channel reserve for mobile wallet users + 2023-10-19T01:55:03.088663+00:00 + + SomberNight 2023-10-18 15:28:41+00:00 + + python-feedgen + + 1 + Removing channel reserve for mobile wallet users + 2023-10-19T01:55:03.088690+00:00 + + The email discusses the process of public attribution in a wallet system. The sender explains how a wallet user can prove certain actions and information related to their wallet provider, specifically in the case of an old state being broadcasted. The sender outlines four points that can be proven by the user:1. A revocation happened: The user can point to the funding transaction output (txo) and the mined commitment transaction being spent via a revocation path.2. The user was one of the participants: This can be proven by signing with one of the multisig funding keys.3. The wallet provider (nodeid) was the other participant: If it was a public channel, the user can show the channel_announcement message. If it was an unannounced channel, the user most likely has a channel_update message for the incoming edge, signed by the wallet provider. However, this is not guaranteed, but often sent in practice.4. Identifying the cheating counterparty: The user can sign a message with the revocationpubkey visible onchain, which was used to spend from the old state. Additionally, the user could prove ownership of the txo created by the revocation, making point (2) redundant.The sender highlights the key insight in point 3/b, where the private channel_update can be shown. Overall, the email provides detailed information on how a wallet user can provide proof in various situations related to their wallet provider. + 2023-10-18T15:28:41+00:00 + + diff --git a/static/lightning-dev/Oct_2023/004141_Removing-channel-reserve-for-mobile-wallet-users.xml b/static/lightning-dev/Oct_2023/004141_Removing-channel-reserve-for-mobile-wallet-users.xml new file mode 100644 index 000000000..ea7f73dbf --- /dev/null +++ b/static/lightning-dev/Oct_2023/004141_Removing-channel-reserve-for-mobile-wallet-users.xml @@ -0,0 +1,18 @@ + + + 1 + Removing channel reserve for mobile wallet users + 2023-10-19T01:54:56.594120+00:00 + + Tony Giorgio 2023-10-18 15:46:31+00:00 + + python-feedgen + + 1 + Removing channel reserve for mobile wallet users + 2023-10-19T01:54:56.594146+00:00 + + The email discusses the main concern regarding the Lightning Service Providers (LSP) not keeping a reserve, which makes it easier for them to steal since the offline concern is on the mobile user. The lack of reliable watch tower integrations/products to mitigate this issue is also mentioned. The question arises on how a user can publish a previous commitment and whether this is something that should be solved for and exposed to users. The email includes a link to the dust reserves that still apply: https://github.com/lightning/bolts/blob/4dcc377209509b13cf89a4b91fde7d478f5b46d8/02-peer-protocol.md?plain=1L304-L308 + 2023-10-18T15:46:31+00:00 + + diff --git a/static/lightning-dev/Oct_2023/combined_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml b/static/lightning-dev/Oct_2023/combined_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml new file mode 100644 index 000000000..3898f6b8e --- /dev/null +++ b/static/lightning-dev/Oct_2023/combined_Batch-exchange-withdrawal-to-lightning-requires-covenants.xml @@ -0,0 +1,39 @@ + + + 2 + Combined summary - Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:52.447877+00:00 + + Bastien TEINTURIER 2023-10-18 14:35:40+00:00 + + + Antoine Riard 2023-10-17 19:10:40+00:00 + + + ZmnSCPxj 2023-10-17 17:17:04+00:00 + + + Greg Sanders 2023-10-17 17:10:42+00:00 + + + ZmnSCPxj 2023-10-17 17:04:06+00:00 + + + Bastien TEINTURIER 2023-10-17 13:03:05+00:00 + + + + + + + + python-feedgen + + 2 + Combined summary - Batch exchange withdrawal to lightning requires covenants + 2023-10-19T01:54:52.447950+00:00 + + The email discusses the sender's efforts to design a protocol for allowing users to withdraw funds from exchanges and deposit them directly into their lightning wallet with minimal on-chain footprint. The current method of enabling lightning withdrawals shifts the burden of making an on-chain transaction to the user's wallet provider, which often requires multiple separate splice transactions if multiple users withdraw funds from an exchange. To address this, the sender suggests batching these transactions into a single transaction without introducing any intermediate transactions.However, a challenge arises as signatures are required from each wallet user for each channel. The availability problem arises as these users may not be online simultaneously, and if one user fails to complete the protocol, the whole batch must be discarded. To overcome this, each wallet user can provide a signature using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` to create a new funding output with the expected amount. This allows users to sign before knowing the final transaction, which the exchange can create by batching pairs of inputs and outputs.Nevertheless, this approach has a fatal flaw as the wallet user cannot spend the new funding output since it is also a 2-of-2 between the wallet user and the wallet provider. This opens the possibility of the wallet provider blackmailing the user to retrieve their funds. In the Lightning Network, this issue is resolved by exchanging signatures for a commitment transaction that returns the funds to their owners before signing the parent funding/splice transaction. However, in this scenario, the `txid` of the batch transaction is unknown, preventing the use of this solution.The sender mentions that they couldn't find a clever workaround for this problem and believes there might not be one. However, the `SIGHASH_ANYPREVOUT` covenant resolves this issue by allowing anyprevout signatures for the commitment transaction, making them valid to spend from the batch transaction. The sender also suggests that other forms of covenants likely address this problem as well.Overall, the email discusses the challenges faced in designing a protocol for lightning withdrawals from exchanges and proposes using covenants, specifically `SIGHASH_ANYPREVOUT`, to overcome these challenges. + 2023-10-18T14:35:40+00:00 + + diff --git a/static/lightning-dev/Oct_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml b/static/lightning-dev/Oct_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml index 1c0022899..80c4131ba 100644 --- a/static/lightning-dev/Oct_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml +++ b/static/lightning-dev/Oct_2023/combined_Full-Disclosure-CVE-2023-40231-CVE-2023-40232-CVE-2023-40233-CVE-2023-40234-All-your-mempool-are-belong-to-us-.xml @@ -1,23 +1,43 @@ 2 - Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" - 2023-10-18T01:58:03.169392+00:00 + Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:54:18.636337+00:00 - ZmnSCPxj 2023-10-17 10:34:04+00:00 + Antoine Riard 2023-10-18 02:57:34+00:00 - ziggie1984 2023-10-17 07:21:35+00:00 + Matt Corallo 2023-10-18 00:17:44+00:00 - - + + Antoine Riard 2023-10-17 18:47:59+00:00 + + + Antoine Riard 2023-10-17 18:34:52+00:00 + + + Antoine Riard 2023-10-17 17:47:14+00:00 + + + Olaoluwa Osuntokun 2023-10-16 22:51:19+00:00 + + + Antoine Riard 2023-10-16 16:57:36+00:00 + + + + + + + + python-feedgen 2 - Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" - 2023-10-18T01:58:03.169440+00:00 - - In this email thread, the sender provides a rephrased explanation of a pinning attack on the Lightning Network (LN). The attack involves three nodes, A, B, and C, connected by channels. The sender explains that the attack exploits a specific scenario where node B has a `cltv_expiry_delta` value of 44 or lower.The attack begins with node A routing an HTLC (Hash Time Lock Contract) from A to B, which is then forwarded from B to C. If C suddenly goes offline, all the signed transactions, including the commitment transaction and HTLC-timeout transactions, become "stuck" at the feerate at the time.At block height 100, node B notices that the HTLC timelock has expired without C claiming it. As a result, node B forces the B-C channel onto the blockchain. However, due to increased onchain feerates, the commitment transaction and HTLC-timeout transaction do not confirm.Meanwhile, node A remains online with B and updates the onchain fees of the A-B channel's pre-signed transactions to the latest fees. At block height 144, node B still cannot claim the A-B HTLC, so node A drops the A-B channel onto the blockchain. Because the fees are up-to-date, this confirmation happens immediately, and node A is able to recover the HTLC funds.However, the pre-signed transactions for the B-C channel still have the old, uncompetitive feerates. At this point, node C broadcasts an HTLC-success transaction with high feerates that Child-Pays-For-Parent (CPFPs) the commitment transaction. This action replaces the HTLC-timeout transaction, which has a low feerate. As a result, C can obtain the value of the HTLC, but B can no longer use the knowledge of the preimage because its own incoming HTLC has already been confirmed as claimed by A.The sender then asks if their restatement of the attack is accurate. They also explain why the HTLC-timeout transaction is pre-signed and why node B cannot feebump it. The Poon-Dryja mechanism infects the HTLCs with a penalty case, which modifies the structure of the HTLCs on the commitment transaction held by B. This modification includes adding a revocation branch and including C in the branch claimable by B in the "plain" HTLC.To prevent B from cheating using an old revoked transaction, the HTLC-timeout transaction spends the B-C-OP_CLTV branch and outputs to a new branch with a relative timelock. Unfortunately, this means that the HTLC-timeout transaction is pre-signed and has a specific feerate. Changing the feerate requires both B and C to agree and re-sign the transaction.The sender highlights that node C has an advantage in fee negotiation because it can Replace-By-Fee (RBF) the HTLC-timeout transaction with fewer bytes compared to B. They suggest that in this scenario, if a lightning node sees the preimage in the mempool and can also claim the output via the HTLC-timeout path, it should aggressively fee-bump its HTLC-output to make the attack more costly for the attacker.Additionally, the sender proposes adding another mitigation for node runners to restrict the amount and number of HTLCs for big channels to unknown peers, as this would limit the potential losses when trying to steal small HTLCs.In conclusion, the email discusses the details of a pinning attack on the Lightning Network, explains the structure of the HTLCs, suggests possible mitigations, and raises questions about monitoring tools and additional attack variations. - 2023-10-17T10:34:04+00:00 + Combined summary - Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" + 2023-10-19T01:54:18.636419+00:00 + + The email discusses the discovery of a new attack on lightning channels called the replacement cycling attack. It explains that this attack poses a risk to the security of funds, even without network mempool congestion. The email also mentions that major lightning implementations have implemented mitigations to prevent this attack, such as aggressive rebroadcasting and local-mempool preimage monitoring. However, it warns that other Bitcoin applications using bitcoin script timelocks or multi-party transactions could also be affected, and developers and operators of these applications should investigate potential disruptions caused by these attacks.The email emphasizes the ongoing efforts to address vulnerabilities in lightning channels and other Bitcoin protocols. It mentions previous attacks, like pinning attacks, that have compromised the safety of lightning channels. Mitigations at the mempool level have been proposed to address pinning attacks, but the replacement cycling attack presents a new challenge.The timeline of events leading up to the discovery and disclosure of this attack spans from 2018 to 2023. The email acknowledges the efforts made by developers and operators to address these vulnerabilities and states that ongoing research and development are essential for the security of Bitcoin protocols and applications. + 2023-10-18T02:57:34+00:00 diff --git a/static/lightning-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml b/static/lightning-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml new file mode 100644 index 000000000..c6fa70df0 --- /dev/null +++ b/static/lightning-dev/Oct_2023/combined_Removing-channel-reserve-for-mobile-wallet-users.xml @@ -0,0 +1,35 @@ + + + 2 + Combined summary - Removing channel reserve for mobile wallet users + 2023-10-19T01:55:30.245840+00:00 + + Tony Giorgio 2023-10-18 15:46:31+00:00 + + + SomberNight 2023-10-18 15:28:41+00:00 + + + Bastien TEINTURIER 2023-10-18 14:47:00+00:00 + + + Tony Giorgio 2023-10-18 14:33:36+00:00 + + + Bastien TEINTURIER 2023-10-18 13:51:11+00:00 + + + + + + + python-feedgen + + 2 + Combined summary - Removing channel reserve for mobile wallet users + 2023-10-19T01:55:30.245898+00:00 + + In this email exchange, Bastien raises the concern about Lightning Service Providers (LSPs) not having a reserve, which makes it easier for them to steal funds. He mentions that there are no reliable watch tower integrations/products available to mitigate this issue. Bastien also questions how users can publish a previous commitment and suggests solving this problem and exposing it to users.Tony responds by acknowledging Bastien's concern and mentioning that in Phoenix (their wallet), they allow the wallet user to have no reserve but require the LSP to meet the usual reserve requirements. Tony seeks clarification from Bastien on what he means by the "dust reserve limit."In his initial email, Bastien discusses the channel reserve requirement and argues that it should be removed for channels between mobile wallet users and their service providers. He explains that the channel reserve ensures that both peers always have an output in the commit transaction, which discourages malicious behavior. However, he highlights the drawbacks of having a channel reserve, including capital inefficiency and a poor user experience. Bastien suggests that removing the reserve on both sides is acceptable because the service provider pays the on-chain fees for the commit transaction and loses something when publishing a revoked commit. For the wallet user, they still get their funds back using penalty transactions. Bastien also notes that the wallet user can publicly show that the service provider published a revoked commitment, which negatively impacts their reputation. Removing the reserve on the wallet user's side is seen as a risk for the wallet provider to ensure a good user experience. Additionally, Bastien draws parallels between LN-penalty without channel reserves and LN-symmetry (Eltoo). He argues that if cheating nodes can always publish a previous commitment in Eltoo with minimal penalties, then it should be acceptable in the current context as well. + 2023-10-18T15:46:31+00:00 + +