From 20409873a88c2fff2c6e60105e0cfa811a218519 Mon Sep 17 00:00:00 2001 From: urvishp80 Date: Wed, 6 Nov 2024 03:15:06 +0000 Subject: [PATCH] Updated homepage.json file --- .../342_Batched-Splicing-Considered-Risky.xml | 24 ++ .../344_Batched-Splicing-Considered-Risky.xml | 18 ++ .../348_Batched-Splicing-Considered-Risky.xml | 20 ++ .../349_Batched-Splicing-Considered-Risky.xml | 22 ++ .../350_Batched-Splicing-Considered-Risky.xml | 24 ++ .../356_Batched-Splicing-Considered-Risky.xml | 22 ++ .../358_Batched-Splicing-Considered-Risky.xml | 20 ++ .../363_Batched-Splicing-Considered-Risky.xml | 18 ++ .../364_Batched-Splicing-Considered-Risky.xml | 24 ++ .../369_Batched-Splicing-Considered-Risky.xml | 18 ++ .../399_Batched-Splicing-Considered-Risky.xml | 20 ++ ...ined_Batched-Splicing-Considered-Risky.xml | 69 +++++ static/homepage.json | 220 +++++++-------- .../Nov_2024/2024-11-06-homepage.json | 262 ++++++++++++++++++ 14 files changed, 666 insertions(+), 115 deletions(-) create mode 100644 static/delvingbitcoin/Nov_2023/342_Batched-Splicing-Considered-Risky.xml create mode 100644 static/delvingbitcoin/Nov_2023/344_Batched-Splicing-Considered-Risky.xml create mode 100644 static/delvingbitcoin/Nov_2023/348_Batched-Splicing-Considered-Risky.xml create mode 100644 static/delvingbitcoin/Nov_2023/349_Batched-Splicing-Considered-Risky.xml create mode 100644 static/delvingbitcoin/Nov_2023/350_Batched-Splicing-Considered-Risky.xml create mode 100644 static/delvingbitcoin/Nov_2023/356_Batched-Splicing-Considered-Risky.xml create mode 100644 static/delvingbitcoin/Nov_2023/358_Batched-Splicing-Considered-Risky.xml create mode 100644 static/delvingbitcoin/Nov_2023/363_Batched-Splicing-Considered-Risky.xml create mode 100644 static/delvingbitcoin/Nov_2023/364_Batched-Splicing-Considered-Risky.xml create mode 100644 static/delvingbitcoin/Nov_2023/369_Batched-Splicing-Considered-Risky.xml create mode 100644 static/delvingbitcoin/Nov_2023/399_Batched-Splicing-Considered-Risky.xml create mode 100644 static/delvingbitcoin/Nov_2023/combined_Batched-Splicing-Considered-Risky.xml create mode 100644 static/homepage/Nov_2024/2024-11-06-homepage.json diff --git a/static/delvingbitcoin/Nov_2023/342_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/342_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..9dec6da6f --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/342_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,24 @@ + + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:13:57.221606+00:00 + + ZmnSCPxj 2023-11-08 20:33:13.829000+00:00 + + python-feedgen + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:13:57.221637+00:00 + + The communication delves into the complexities and vulnerabilities associated with splicing transactions within the Lightning Network, especially when integrating a sub-protocol that enables the addition of arbitrary inputs and outputs to facilitate batching of on-chain operations alongside splicings. The hypothetical scenario presented illustrates a situation where a user attempts to execute a spliced transaction involving multiple channels, aiming to redistribute funds amongst peers, including opening a new channel. However, this process is susceptible to disruptions by malicious actors, as demonstrated by a competitor's ability to double-spend a pre-splice transaction, thereby not only undermining the original transaction but also inadvertently causing harm to other parties involved. + +This vulnerability is rooted in the absence of disincentives for disrupting such transactions, given that traditional mechanisms like routing fees do not apply in the context of splicing. This issue is further compounded in scenarios where peers possess little to no reserve funds, making them more inclined to engage in disruptive behaviors despite potential losses. The text suggests that even with strategies to mitigate these risks, such as periodic recreation of splice transactions or leveraging `SIGHASH_ANYPREVOUT` for more flexible transaction confirmation criteria, challenges persist. These include increased operational complexity, heightened susceptibility to bugs, and potential exacerbation of trust issues in zero-confirmation channel use cases. + +Moreover, the discussion highlights how the current Lightning Network's architecture, without splice, naturally disincentivizes disruption through circular routing rebalances, a mechanism absent in splicing. This absence indicates a fundamental shift in risk profile when moving liquidity via splicing compared to traditional methods. Consequently, batched splicing is deemed risky under certain conditions, particularly when it involves channels with peers who may have incentives to disrupt the operation. + +In summary, while splicing offers a promising avenue for enhancing the efficiency and flexibility of channel management on the Lightning Network, it introduces significant security and operational challenges. These challenges necessitate careful consideration and potentially innovative solutions to mitigate risks without undermining the network's integrity or user trust. + 2023-11-08T20:33:13.829000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2023/344_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/344_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..267bc4a8b --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/344_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,18 @@ + + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:14:43.216433+00:00 + + Greg Sanders 2023-11-08 15:21:03.881000+00:00 + + python-feedgen + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:14:43.216459+00:00 + + To provide a summary based on the given instructions, I'll need the content of the email or the details you want summarized. The context provided indicates an anticipation of a discussion potentially centered around zero-confirmation transactions (0-conf). However, without the actual content or detailed points from the email, it's challenging to compose a blog post summary adhering to your guidelines. Please share more information or key points from the communication you're referring to, so an effective summary can be crafted following the rules you've outlined. + 2023-11-08T15:21:03.881000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2023/348_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/348_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..cb4105f35 --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/348_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,20 @@ + + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:14:37.202391+00:00 + + ZmnSCPxj 2023-11-08 17:53:00.053000+00:00 + + python-feedgen + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:14:37.202423+00:00 + + The distinction between offchain transactions and 0-conf transactions is crucial in understanding the security and trust mechanisms that underpin them. Offchain transactions are characterized by a single input signed by all parties involved, requiring unanimous consensus for any changes. This mechanism inherently protects against double-spending, as all signatories must agree to any transaction, essentially making unauthorized transactions impossible without full cooperation. In contrast, 0-conf transactions can be approved by a single participant, making them more vulnerable to double-spending attacks since a transaction could be altered or not include funds promised to a receiver after the initial agreement. + +A significant concern arises with splice-in designs, which aim to blend the characteristics of both offchain and 0-conf transactions. These designs typically involve one input that operates on an n-of-n consensus basis (similar to offchain transactions) but also include additional inputs that may only require a single signature from one of the parties involved (mirroring 0-conf transactions). This structure presents a security risk by potentially allowing an individual participant to execute a double-spend attack on the splice transaction. By combining elements of both transaction types, splice designs inadvertently inherit the vulnerabilities of 0-conf transactions while compromising the security assurances provided by fully offchain methods. This blend creates a scenario where the theoretical safety and consensus benefits of offchain transactions are diluted by the introduction of 0-conf's susceptibility to unilateral actions by individual participants. + 2023-11-08T17:53:00.053000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2023/349_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/349_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..4baa26cfc --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/349_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,22 @@ + + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:14:24.550021+00:00 + + ZmnSCPxj 2023-11-08 17:58:01.698000+00:00 + + python-feedgen + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:14:24.550052+00:00 + + The existing splice design in Lightning Network transactions involves two sets of commitment transactions: one set for before the splice (pre-splice) and another set for after the splice (post-splice). This structure is adequate when dealing with the splicing of funds in a single channel. However, challenges arise when considering the simultaneous splicing of multiple channels within a single batched transaction. Such scenarios might include a node desiring to transfer funds out of one channel and into another. + +A significant issue with the current design becomes apparent during theft attempts. Specifically, if an attacker publishes a revoked commitment transaction for one channel, it might block the confirmation of the splice transaction for all other involved channels. This potential vulnerability is exacerbated in situations where the cost of attempting theft is minimal or non-existent. For instance, channels that were opened with funds from only one party and have never facilitated incoming transactions for the attacker pose little to no risk for attempting theft. In these cases, the victim has a strong incentive to remove their funds from the compromised channel through splicing. + +This overview highlights critical considerations for enhancing the security and functionality of splice transactions within the Lightning Network, especially when managing funds across multiple channels simultaneously. The need for a design that can accommodate the complexities of batched splice transactions without exposing users to increased risks of theft is evident. + 2023-11-08T17:58:01.698000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2023/350_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/350_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..a7feeab19 --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/350_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,24 @@ + + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:14:13.973685+00:00 + + ajtowns 2023-11-08 19:35:16.019000+00:00 + + python-feedgen + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:14:13.973716+00:00 + + The discussion revolves around the complexities and potential vulnerabilities associated with channel management in blockchain networks, focusing on scenarios involving double-spending, splicing, and channel reopening strategies. One critical point raised is the possibility of a party, referred to as B, exploiting the system by using a revoked commitment transaction to double-spend within a pre-spliced channel. This maneuver raises questions about the necessity and security of choosing between a normal unilateral close, utilizing the current non-splice commitment transaction, and the mechanisms to regain access to funds for further transactions with other parties, such as C and D. + +The conversation further explores the implications of a naive action taken by D, who proceeds to send the preimage to the Hash Time-Locked Contract (HTLC) for the Just-In-Time (JIT) channel payment upon witnessing the broadcast of a batched transaction. This scenario underlines the risk associated with forwarding HTLCs without considering the suitability of the channel for zero-confirmation (zeroconf) use, especially when not all inputs are controlled by the forwarding party. The dialogue suggests exploring advanced versions of zeroconf channels that could accommodate entirely new funding transactions without necessitating the closure and reopening of the channel, though it acknowledges the current limitations in achieving such functionality. + +There's also a discussion on the need for flexibility in managing channel funds and relationships, especially in situations where a splice operation involves changing participants or funding sources. Specifically, the ability to revert to original channel funding outputs without closing existing channels is highlighted as a desirable feature. This becomes particularly relevant when a splice transaction is rendered obsolete due to the prior spending of a targeted unspent transaction output (UTXO), indicating that dropping the splice transaction under these circumstances should be an acceptable resolution. + +In summary, the conversation touches upon several intricate aspects of channel operations within blockchain frameworks, including the challenges of preventing double-spending in channel splicing, the technical considerations for safely forwarding HTLCs, the potential for advanced channel management features to support dynamic funding arrangements, and the procedural nuances involved in adjusting splice transactions following UTXO spending events. + 2023-11-08T19:35:16.019000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2023/356_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/356_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..1e9a0de1d --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/356_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,22 @@ + + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:13:38.771345+00:00 + + ZmnSCPxj 2023-11-09 00:27:50.609000+00:00 + + python-feedgen + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:13:38.771379+00:00 + + The discussion highlights the inherent complexities and necessary precautions when implementing splicing in conjunction with Just-In-Time (JIT) channel openings within the Lightning Network (LN). It is emphasized that batching splices with JIT channel openings is not feasible due to the nature of JIT operations, which open channels in response to forwarding Hash Time-Locked Contracts (HTLCs). This necessitates a nuanced approach to coordination between peers, akin to the `channel_ready` signaling but tailored for splice operations, introducing concepts like `splice_cancelled` or `splice_ready`. Such coordination is crucial as it requires implementations to actively monitor blockchain transactions rather than relying on timeouts. This is because splice transactions, while remaining valid, can be unconfirmed for an extended period due to mempool congestion, during which there's a risk of double-spending by the peer. + +Furthermore, the discourse suggests the need for protocol-level messaging, such as a `splice_cancelled` message, to facilitate better communication and management of splice operations. This aspect underlines the potential incentives for participants to disrupt splice agreements, particularly to penalize others for moving funds without incurring routing fees that would otherwise benefit them in a traditional LN setup without splicing. The traditional model incentivizes routing through fees, whereas splicing allows for fund movement without direct compensation to those facilitating the network's liquidity. + +To address these challenges and potential disputes over splice operations, it's proposed that there should be mechanisms to reject incoming splice-out requests. Additionally, the conversation points towards the introduction of negotiation facilities within the LN for determining in-network fees for splicing out. These measures aim to ensure fair compensation for participants affected by splice-outs and maintain the integrity and incentive structure of the LN ecosystem. This dialogue underscores the intricate balance between innovation in payment channel technologies and the necessity of maintaining a cooperative and mutually beneficial network environment. + 2023-11-09T00:27:50.609000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2023/358_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/358_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..949922c84 --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/358_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,20 @@ + + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:13:25.732040+00:00 + + ajtowns 2023-11-09 01:07:07.047000+00:00 + + python-feedgen + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:13:25.732071+00:00 + + The technical intricacies of batching a splice with a Just-In-Time (JIT) channel reveal the limitations and considerations necessary for such operations. The essence of the challenge lies in the nature of JIT channels, which are specifically designed to open in response to an HTLC (Hashed Time-Locked Contract) that needs to be forwarded. This dynamic complicates the process of funding a zero confirmation channel, particularly because it is advisable only to do so when all inputs are securely under one's control. This includes the careful handling of unconfirmed inputs, aside from one's own change, to mitigate any potential risks. + +In scenarios where trust and Know Your Customer (KYC) protocols are established, there exists a workaround to the aforementioned limitation. This involves routing the HTLC payment into a custodial account first, rather than directly opening a channel. Subsequently, the channel can be opened from this custodial account. Such a mechanism offers a safeguard: should the splice attempt fail, the channel opening is aborted, allowing the funds to revert to the custodial account instead of becoming stuck within the channel. This approach underscores the importance of control and the ability to manage funds effectively in the context of channel operations and HTLC transactions. + 2023-11-09T01:07:07.047000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2023/363_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/363_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..1a19e889f --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/363_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,18 @@ + + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:13:15.145831+00:00 + + ZmnSCPxj 2023-11-09 08:14:33.548000+00:00 + + python-feedgen + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:13:15.145863+00:00 + + The necessity for a `splice_cancelled` feature within the splice protocol is highlighted due to the current lack of options when a splice transaction fails to confirm. This feature would provide a means to retract from a splice without having to resort to unilateral closure of channels. The concern stems from the risky nature of batched splices involving multiple participants. In such scenarios, the failure of one participant's transaction to confirm could lead to the unilateral closing of all other involved channels. This scenario underscores the importance of developing mechanisms for safe withdrawal from failed splice transactions, thereby mitigating the risks associated with batched splice operations. The discussion points towards an area in the splice protocol that requires further development to enhance reliability and safety for users engaging in complex transactions involving multiple parties. + 2023-11-09T08:14:33.548000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2023/364_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/364_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..dbec2e1b4 --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/364_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,24 @@ + + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:13:07.246231+00:00 + + ajtowns 2023-11-09 08:25:56.667000+00:00 + + python-feedgen + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:13:07.246264+00:00 + + When exploring the advancements in technology, particularly in programming and software development, it's essential to consider the contributions from various sources. The information provided through resources such as [Lightning Splice Specifications](https://lightningsplice.com/splicing_spec.html) and contributions on GitHub like [BOLTs Pull Request #863](https://github.com/lightning/bolts/pull/863/) are significant. These resources shed light on the technical intricacies and the collaborative nature of software development. + +The Lightning Network is a decentralized system, aiming at instant, high-volume micropayments that remove the need for custody by leveraging blockchain smart contracts. The specification detailed on the Lightning Splice website introduces comprehensive protocols designed to enhance scalability and efficiency within this network. It signifies a step forward in addressing some of the most pressing challenges faced by digital payments systems, including speed, cost, and trust issues. + +On the other hand, the GitHub contribution underlines the collaborative efforts within the programming community to refine and evolve existing technologies. The discussion in BOLTs Pull Request #863 showcases an active engagement among developers to address and rectify potential vulnerabilities, improve functionality, and introduce new features that can lead to more robust and secure systems. This process not only highlights the importance of community involvement in the open-source ecosystem but also demonstrates a commitment to continuous improvement and innovation. + +These examples emphasize the dynamic and evolving nature of technology. They illustrate the critical role of collaboration, open dialogue, and shared knowledge in driving progress. By examining these resources, one can gain insights into the complexities of software development and the collective effort required to push the boundaries of what is possible in the digital realm. + 2023-11-09T08:25:56.667000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2023/369_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/369_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..d98857e87 --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/369_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,18 @@ + + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:12:54.299139+00:00 + + ZmnSCPxj 2023-11-10 00:43:16.879000+00:00 + + python-feedgen + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:12:54.299171+00:00 + + The email highlights the possibility of having multiple splice transactions in-flight within a network, suggesting that managing these transactions is feasible by adjusting certain parameters. Specifically, it mentions the strategy of removing an offending channel from a batch as a viable solution to potential issues, provided there is a willingness to increase the feerate. This approach implies a level of flexibility in handling transactions but also underscores the necessity for a batched splicing implementation to actively monitor for such scenarios. The discussion points towards a technical consideration in the management of splice transactions, emphasizing the balance between operational flexibility and the need for vigilant monitoring to ensure smooth transaction flows. + 2023-11-10T00:43:16.879000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2023/399_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/399_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..7057afa13 --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/399_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,20 @@ + + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:12:47.928252+00:00 + + t-bast 2023-11-14 08:23:01.648000+00:00 + + python-feedgen + + 1 + Batched Splicing Considered Risky + 2024-11-06T03:12:47.928291+00:00 + + In the realm of current implementations by cln and eclair, there's an inherent necessity to monitor for double-spending due to the potential addition of inputs by peers that are outside one's control. This process becomes crucial when considering the dynamics of unconfirmed splice transactions within a channel. Specifically, when such a transaction is double spent by an unrelated transaction not aimed at splicing for that channel, it introduces a scenario where the existing systems lack a formal mechanism for its removal from the pending splice transaction list. However, this perceived limitation is argued against on the grounds of unnecessary complexity. + +The stance taken suggests a different approach where the splice transaction, despite being double spent, remains within the list of pending splice transactions. The proposal advocates for sending a `commit_sig` for the affected transaction whenever the channel is utilized. This method is highlighted as having minimal overhead, offering a streamlined solution to the issue at hand. Furthermore, it assures an automatic cleanup of the splice transaction once another splice transaction successfully confirms. This approach simplifies the operational framework while effectively addressing the challenge posed by double spends in the context of unconfirmed splice transactions. + 2023-11-14T08:23:01.648000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2023/combined_Batched-Splicing-Considered-Risky.xml b/static/delvingbitcoin/Nov_2023/combined_Batched-Splicing-Considered-Risky.xml new file mode 100644 index 000000000..7a8ad77c2 --- /dev/null +++ b/static/delvingbitcoin/Nov_2023/combined_Batched-Splicing-Considered-Risky.xml @@ -0,0 +1,69 @@ + + + 2 + Combined summary - Batched Splicing Considered Risky + 2024-11-06T03:15:03.546347+00:00 + + t-bast 2023-11-14 08:23:01.648000+00:00 + + + ZmnSCPxj 2023-11-10 00:43:16.879000+00:00 + + + ajtowns 2023-11-09 08:25:56.667000+00:00 + + + ZmnSCPxj 2023-11-09 08:14:33.548000+00:00 + + + ajtowns 2023-11-09 01:07:07.047000+00:00 + + + ZmnSCPxj 2023-11-09 00:27:50.609000+00:00 + + + ZmnSCPxj 2023-11-08 20:33:13.829000+00:00 + + + ajtowns 2023-11-08 19:35:16.019000+00:00 + + + ZmnSCPxj 2023-11-08 17:58:01.698000+00:00 + + + ZmnSCPxj 2023-11-08 17:53:00.053000+00:00 + + + Greg Sanders 2023-11-08 15:21:03.881000+00:00 + + + + + + + + + + + + + python-feedgen + + 2 + Combined summary - Batched Splicing Considered Risky + 2024-11-06T03:15:03.546483+00:00 + + The discussions around the implementation and challenges of splicing transactions in Lightning Network (LN) protocols reveal several technical nuances and considerations vital for developers and stakeholders in the cryptocurrency domain. Splicing, as an operation that allows for the adjustment of funds within a LN channel without closing it, presents both opportunities and risks, particularly when involving multiple parties or attempting to integrate with just-in-time (JIT) channel openings. + +One significant area of concern is the vulnerability to double-spend attacks, where a transaction meant to splice funds can be invalidated by another transaction spending the same inputs. The issue is exacerbated in scenarios where multiple splicing transactions are batched together, aiming for efficiency but risking cascading failures if one splice transaction fails. This risk highlights the necessity for a `splice_cancelled` message within the protocol to allow for a graceful exit from failed splice attempts without resorting to unilateral channel closures, which would negatively impact all participants involved. + +Moreover, the concept of batching splices with JIT channel opens is critically examined. JIT operations, designed to enhance liquidity and reduce delays in forwarding payments through the network, are inherently incompatible with the unpredictability and security concerns of batched splicing. The reliance on zero-confirmation transactions further complicates this, as it increases susceptibility to fraud and double-spending, undermining the integrity of JIT channels. + +The dialogue also touches upon the broader implications of splicing in network dynamics, such as the potential for malicious actors to disrupt operations not only directly through double-spending but indirectly by exploiting the interconnectedness of batched transactions. Such disruptions could lead to unintended consequences across the network, damaging trust and operational stability. The proposed solutions, including periodic recreation of splice transactions and the use of `SIGHASH_ANYPREVOUT` for more flexible transaction management, reflect ongoing efforts to address these challenges. + +Links to relevant resources like the splicing specification and GitHub discussions provide additional context and underscore the collaborative nature of solving these complex issues. As these conversations evolve, they contribute to refining the technical foundations and strategic approaches necessary for the development of robust, secure, and efficient cryptocurrency networks. + +For further reading and technical details, reference materials can be found at [Splicing Spec](https://lightningsplice.com/splicing_spec.html) and the GitHub pull request [GitHub PR #863](https://github.com/lightning/bolts/pull/863/). + 2023-11-14T08:23:01.648000+00:00 + + diff --git a/static/homepage.json b/static/homepage.json index f4184c88a..294de0b32 100644 --- a/static/homepage.json +++ b/static/homepage.json @@ -1,6 +1,21 @@ { - "header_summary": "Adam Borcany proposes a novel method for enhancing Bitcoin transaction security through proof-of-work (PoW) locked outputs, offering a more granular difficulty adjustment than traditional signature grinding allows. By utilizing a predetermined set of signatures and private keys, this approach avoids reliance on complex calculations, aiming for a more efficient and flexible system. This development could improve the scalability and adaptability of securing Bitcoin transactions, as demonstrated by a Node.JS application example detailed in Borcany's explanation ([source](https://gnusha.org/pi/bitcoindev/CAOY=fzk-ksDGT_oyCKF=EJnnXaXoCbfCzxW+9PBQV=us-K=PuQ@mail.gmail.com/T/#u#m6466fc7480c6cde4dc938a788051920242c7231c)).\n\nThe release of Bitcoin Core version 27.2, announced by Michael Ford and fanquake, introduces several key updates, including bug fixes, performance enhancements, and updated translations, accessible for download through the official website or BitTorrent. This version, tested across various operating systems, remains compatible with older wallet versions, ensuring a broad user base can benefit from the improvements. The developers have made significant efforts to address issues such as race conditions, shutdown order, and PSBT processing, underlining the community-driven nature of Bitcoin Core's evolution ([Bitcoin Core's official website](https://bitcoincore.org/bin/bitcoin-core-27.2/)).\n\nIn the Lightning protocol sphere, morehouse highlights a critical issue where the failure to update off-chain channel states can lead to inefficient force closures, exacerbated by Output Power Reduction (OPR). This scenario underscores the balance between transaction efficiency and the risk to channel balances, posing a challenge for maintaining the protocol's integrity. Meanwhile, ZmnSCPxj introduces the SuperScalar mechanism as a solution to the Lightning Network's Last-Mile Problem, offering a decentralized approach to liquidity provisioning without compromising security. This mechanism aims to enhance scalability and user experience, showcasing ongoing innovations in Lightning Network protocols ([source](https://delvingbitcoin.org/t/a-fast-scalable-protocol-for-resolving-lightning-payments/1233/2)).", + "header_summary": "Antoine Poinsot announced the release of new security advisories addressing historical issues in Bitcoin Core, emphasizing the project's commitment to transparent security practices. These advisories, along with a detailed disclosure policy, can be found on their [official website](https://bitcoincore.org/en/2024/11/05/cb-stall-hindering-propagation) and highlight the completion of a process initiated in July to enhance security transparency.\n\nAdam Borcany introduced an innovative approach for securing Bitcoin transactions through proof-of-work (PoW) locked outputs, offering a more granular difficulty adjustment than current methods. This novel method, bypassing the limitations of signature grinding by using a fixed set of signatures and private keys, suggests a more efficient and flexible system for transaction security, as outlined in a [detailed discussion](https://gnusha.org/pi/bitcoindev/CAOY=fzk-ksDGT_oyCKF=EJnnXaXoCbfCzxW+9PBQV=us-K=PuQ@mail.gmail.com/T/#u#m6466fc7480c6cde4dc938a788051920242c7231c).\n\nResearch highlighted by cndolo reveals potential censorship vulnerabilities within the Lightning Network, caused by the centralization of network layers and the identifiability of TCP headers. The study proposes several countermeasures, such as adaptive padding techniques and leveraging AS information in pathfinding algorithms, to enhance resistance against censorship, emphasizing the need for improved privacy and decentralization measures within the network. The full exploration of these vulnerabilities and proposed solutions is available at [Delving Bitcoin](https://delvingbitcoin.org/t/research-paper-on-ln-payment-censorship/1248).\n\nZmnSCPxj proposes the SuperScalar mechanism to address the Lightning Service Provider (LSP) Last-Mile Problem, enabling efficient and secure liquidity provisioning without blockchain consensus changes. This comprehensive solution leverages Decker-Wattenhofer channel factories, timeout trees, and pseudo-Spilman leaves to facilitate scalability, security, and decentralized liquidity management, marking a significant advancement in addressing the challenges of incoming liquidity for new users on the Lightning Network. The technical details and implications of this proposal are discussed at [Delving Bitcoin](https://delvingbitcoin.org/t/superscalar-laddered-timeout-tree-structured-decker-wattenhofer-factories-with-pseudo-spilman-leaves/1242).", "recent_posts": [ + { + "id": "m1bab216dee18c20e39cbf90f1261a736c18cd3a1", + "title": "Public disclosure of one vulnerability affecting Bitcoin Core <26.0", + "link": "https://gnusha.org/pi/bitcoindev/uJpfg8UeMOfVUATG4YRiGmyz5MALtZq68FCBXA6PT-BNstodivpqQfDxD1JAv5Qny_vuNr-A1m8jIDNHQLhAQt8hj8Ee9OT6ZFE5Z16O97A=@protonmail.com/T/#u#m1bab216dee18c20e39cbf90f1261a736c18cd3a1", + "authors": [ + "Antoine Poinsot" + ], + "published_at": "2024-11-05T16:00:00+00:00", + "summary": "- The latest Bitcoin Core security advisories are available on their official website.\n- New vulnerabilities will follow a publicly advertised disclosure policy henceforth.\n- This signifies the project's drive for transparent and responsible security practices.", + "n_threads": 0, + "dev_name": "bitcoin-dev", + "contributors": [], + "file_path": "static/bitcoin-dev/Nov_2024/m1bab216dee18c20e39cbf90f1261a736c18cd3a1_Public-disclosure-of-one-vulnerability-affecting-Bitcoin-Core-26-0.xml", + "combined_summ_file_path": "" + }, { "id": "m6466fc7480c6cde4dc938a788051920242c7231c", "title": "Bitcoin PoW locked outputs with arbitrary difficulty", @@ -9,7 +24,7 @@ "Adam Borcany" ], "published_at": "2024-11-04T15:34:00+00:00", - "summary": "- A novel PoW method for Bitcoin security avoids coarse adjustments, employs short DER-encoded signatures.\n- This technique allows for precise difficulty adjustments using two private keys and short signature criteria.\n- Demonstrated through a Node.JS application, it enables smoother security adjustments for Bitcoin transactions.", + "summary": "- Adam Borcany discusses a new Bitcoin transaction security method beyond signature grinding.\n- This method allows flexible difficulty adjustments using mathematical intervals, not relying on elliptic calculations.\n- It proposes a practical application with Node.JS, enhancing the security and adaptability of PoW-locked outputs.", "n_threads": 0, "dev_name": "bitcoin-dev", "contributors": [], @@ -17,35 +32,36 @@ "combined_summ_file_path": "" }, { - "id": "mdabc1118c9d2fe5e0e777e50d77308aa3fab2c41", - "title": "Bitcoin Core 27.2 released", - "link": "https://gnusha.org/pi/bitcoindev/CAFyhPjWx0qSuBgBqboxWwWjkFZPbsWrEx8sW0Me8=kXQRppbbg@mail.gmail.com/T/#u#mdabc1118c9d2fe5e0e777e50d77308aa3fab2c41", + "id": "3490", + "title": "Research Paper on LN Payment Censorship", + "link": "https://delvingbitcoin.org/t/research-paper-on-ln-payment-censorship/1248", "authors": [ - "Michael Ford" + "cndolo" ], - "published_at": "2024-11-04T13:06:00+00:00", - "summary": "- The release of Bitcoin Core version 27.2 has been announced, offering several improvements and bug fixes.\n- This update supports multiple operating systems and emphasizes the need for users to report any encountered bugs.\n- Significant changes include the fixing of race conditions, improvements in initialization and PSBT functionality, and enhanced compatibility with new software versions.", + "published_at": "2024-11-05T11:57:11.703000+00:00", + "summary": "- Recent research highlights Lightning Network's vulnerability to censorship by network-level adversaries. - It details how attackers could manipulate LN transactions without detection by exploiting network centralization. - Proposed countermeasures include adaptive padding and incorporating AS information into pathfinding to improve resilience.", "n_threads": 0, - "dev_name": "bitcoin-dev", + "dev_name": "delvingbitcoin", "contributors": [], - "file_path": "static/bitcoin-dev/Nov_2024/mdabc1118c9d2fe5e0e777e50d77308aa3fab2c41_Bitcoin-Core-27-2-released.xml", + "file_path": "static/delvingbitcoin/Nov_2024/3490_Research-Paper-on-LN-Payment-Censorship.xml", "combined_summ_file_path": "" }, { - "id": "3482", + "id": "3488", "title": "A Fast, Scalable Protocol For Resolving Lightning Payments", - "link": "https://delvingbitcoin.org/t/a-fast-scalable-protocol-for-resolving-lightning-payments/1233/2", + "link": "https://delvingbitcoin.org/t/a-fast-scalable-protocol-for-resolving-lightning-payments/1233/3", "authors": [ - "morehouse" + "harding" ], - "published_at": "2024-11-04T23:59:52.234000+00:00", - "summary": "- Alice failing to update off-chain states puts Bob in a dilemma regarding HTLC transactions.\n- Increased Output Power Reduction (OPR) costs discourage resolving minor HTLC discrepancies.\n- OPR enhances payment resolution speed at the expense of higher user capital requirements.", - "n_threads": 1, + "published_at": "2024-11-05T10:14:19.731000+00:00", + "summary": "- The article analyzes vulnerabilities in the Offchain Payment Routing system, focusing on exploitable free probes.\n- It suggests incremental routing fee increases to cover losses from node failures, though costs could rise significantly.\n- It explores probabilistic payments as a scalable workaround for high HTLC settlement costs, noting limited progress.", + "n_threads": 2, "dev_name": "delvingbitcoin", "contributors": [ - "JohnLaw" + "JohnLaw", + "morehouse" ], - "file_path": "static/delvingbitcoin/Nov_2024/3482_A-Fast-Scalable-Protocol-For-Resolving-Lightning-Payments.xml", + "file_path": "static/delvingbitcoin/Nov_2024/3488_A-Fast-Scalable-Protocol-For-Resolving-Lightning-Payments.xml", "combined_summ_file_path": "static/delvingbitcoin/Nov_2024/combined_A-Fast-Scalable-Protocol-For-Resolving-Lightning-Payments.xml" }, { @@ -56,48 +72,15 @@ "ZmnSCPxj" ], "published_at": "2024-11-04T15:40:11.090000+00:00", - "summary": "- SuperScalar aims to solve Bitcoin's LSP Last-Mile Problem with innovative liquidity solutions.\n- It employs Decker-Wattenhofer mechanisms, timeout trees, and pseudo-Spilman channel factories for robust security.\n- The mechanism disincentivizes dishonesty, ensuring system integrity without Bitcoin blockchain consensus changes.", + "summary": "- SuperScalar aims to resolve the Bitcoin Lightning Network's liquidity issues securely and efficiently.\n- It employs advanced mechanisms like Decker-Wattenhofer and pseudo-Spilman channel factories for scalability.\n- This construction ensures safety, prevents misuse by LSPs, and encourages user and network integrity.", "n_threads": 0, "dev_name": "delvingbitcoin", "contributors": [], "file_path": "static/delvingbitcoin/Nov_2024/3469_SuperScalar-Laddered-Timeout-Tree-Structured-Decker-Wattenhofer-Factories-With-Pseudo-Spilman-Leaves.xml", "combined_summ_file_path": "" - }, - { - "id": "3464", - "title": "Bitcoin Core 27.2 Released", - "link": "https://delvingbitcoin.org/t/bitcoin-core-27-2-released/1239", - "authors": [ - "fanquake" - ], - "published_at": "2024-11-04T10:50:46.936000+00:00", - "summary": "- Bitcoin Core version 27.2 is now available, featuring improvements and bug fixes aimed at better performance.\n- The update supports Linux Kernel version 3.17+, macOS 11.0+, and Windows 7 or newer, advising against use on unsupported systems.\n- Significant changes include solutions for race conditions, system stability enhancements, and functionality improvements across the software.", - "n_threads": 0, - "dev_name": "delvingbitcoin", - "contributors": [], - "file_path": "static/delvingbitcoin/Nov_2024/3464_Bitcoin-Core-27-2-Released.xml", - "combined_summ_file_path": "" } ], "active_posts": [ - { - "id": "ma5658318128c12ee3958e6713df5d809230c7d5f", - "title": "Redefine packages to discourage address reuse", - "link": "https://gnusha.org/pi/bitcoindev/b383aad2-1abc-4b82-9851-1750b1b52f12n@googlegroups.com/T/#u#ma5658318128c12ee3958e6713df5d809230c7d5f", - "authors": [ - "/dev /fd0" - ], - "published_at": "2024-10-20T06:19:00+00:00", - "summary": "- Address reuse in Bitcoin transactions compromises privacy, prompting a strategy of modifying mempool policies.\n- BIP 331's package transactions concept, organizing transactions in a Directed Acyclic Graph, could improve privacy.\n- Challenges include implementation hurdles and the need for efficient address reuse checks within Bitcoin Core.", - "n_threads": 5, - "dev_name": "bitcoin-dev", - "contributors": [ - "Peter Todd", - "Abubakar Ismail" - ], - "file_path": "static/bitcoin-dev/Oct_2024/ma5658318128c12ee3958e6713df5d809230c7d5f_Redefine-packages-to-discourage-address-reuse.xml", - "combined_summ_file_path": "static/bitcoin-dev/Oct_2024/combined_Redefine-packages-to-discourage-address-reuse.xml" - }, { "id": "mb513065fc5985f1a474e7537ca7720288d8f9579", "title": "libsecp256k1 v0.6.0 released", @@ -106,7 +89,7 @@ "Jonas Nick" ], "published_at": "2024-11-04T17:45:00+00:00", - "summary": "- The latest version 0.6.0 of libsecp256k1 has been officially released.\n- It introduces a MuSig2 module and enhanced security for clearing secrets.\n- Unused functions were removed to streamline the library, with details on GitHub.", + "summary": "- The latest version 0.6.0 of libsecp256k1 introduces several updates and improvements.\n- It features a MuSig2 module and a method for more secure clearing of secrets.\n- Unused secp256k1_scratch_space functions were removed, streamlining the library.", "n_threads": 0, "dev_name": "bitcoin-dev", "contributors": [], @@ -121,13 +104,28 @@ "Robert Netzke" ], "published_at": "2024-11-04T18:29:00+00:00", - "summary": "- Robert Netzke proposes a new file format for Bitcoin wallet descriptors.\n- The format simplifies inheritance and enhances interoperability between services.\n- It seeks feedback and may align with PSBT data encoding for developer ease.", + "summary": "- Robert Netzke introduces a file format for easy Bitcoin wallet descriptor recovery.\n- The format aids inheritance, inter-service interoperability, and simplifies backups.\n- Feedback is sought for refining the approach and its practical implementation.", "n_threads": 0, "dev_name": "bitcoin-dev", "contributors": [], "file_path": "static/bitcoin-dev/Nov_2024/m0927acdfbd44f01a5509d914c9d12e44f95fe033_File-Format-for-Wallet-Inheritance-and-Recovery.xml", "combined_summ_file_path": "" }, + { + "id": "mdabc1118c9d2fe5e0e777e50d77308aa3fab2c41", + "title": "Bitcoin Core 27.2 released", + "link": "https://gnusha.org/pi/bitcoindev/CAFyhPjWx0qSuBgBqboxWwWjkFZPbsWrEx8sW0Me8=kXQRppbbg@mail.gmail.com/T/#u#mdabc1118c9d2fe5e0e777e50d77308aa3fab2c41", + "authors": [ + "Michael Ford" + ], + "published_at": "2024-11-04T13:06:00+00:00", + "summary": "- Bitcoin Core version 27.2 has been released, featuring bug fixes and performance enhancements.\n- Users can download the new version from the official website or via BitTorrent.\n- The update supports older wallet versions and has been tested on several operating systems.", + "n_threads": 0, + "dev_name": "bitcoin-dev", + "contributors": [], + "file_path": "static/bitcoin-dev/Nov_2024/mdabc1118c9d2fe5e0e777e50d77308aa3fab2c41_Bitcoin-Core-27-2-released.xml", + "combined_summ_file_path": "" + }, { "id": "1996", "title": "Great Consensus Cleanup Revival", @@ -136,8 +134,8 @@ "AntoineP" ], "published_at": "2024-03-24T19:53:27.073000+00:00", - "summary": "- The proposal highlights vulnerabilities in the Bitcoin protocol, suggesting improvements for security and efficiency.\n- It addresses the timewarp vulnerability, proposes constraints on non-SegWit transactions, and suggests invalidating small transactions.\n- Community debate centers on block size reduction and standardizing technical elements, reflecting concerns over scalability and established practices.", - "n_threads": 45, + "summary": "- The analysis suggests improvements in the Bitcoin protocol to enhance security and efficiency.\n- It proposes solutions for vulnerabilities like the timewarp exploit and inefficient block validation.\n- Community debate surrounds certain suggestions, reflecting concerns over network scalability and functionality.", + "n_threads": 46, "dev_name": "delvingbitcoin", "contributors": [ "ajtowns", @@ -163,7 +161,7 @@ "reardencode" ], "published_at": "2024-01-07T18:41:08.593000+00:00", - "summary": "- New Bitcoin features propose enhancements for Lightning Network and future developments.\n- Proposed changes introduce output restricting covenants, improving control over Bitcoin spending.\n- Enhancements aim to improve Bitcoin's scalability, privacy, and efficiency in financial innovation.", + "summary": "- Recent Bitcoin protocol updates propose features enhancing Lightning Network capabilities.\n- Proposed changes include BIP119 and new opcodes, aiming to introduce output restricting covenants.\n- These enhancements could improve Bitcoin's scalability, privacy, and utility significantly.", "n_threads": 17, "dev_name": "delvingbitcoin", "contributors": [ @@ -181,92 +179,84 @@ "combined_summ_file_path": "static/delvingbitcoin/Jan_2024/combined_LNHANCE-bips-and-implementation.xml" }, { - "id": "3401", - "title": "OP_PAIRCOMMIT as a candidate for addition to LNhance", - "link": "https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216", + "id": "3432", + "title": "Libbitcoin for Core people", + "link": "https://delvingbitcoin.org/t/libbitcoin-for-core-people/1222", "authors": [ - "moonsettler" + "AntoineP" ], - "published_at": "2024-10-25T14:34:33.286000+00:00", - "summary": "- The email explores optimizing SHA256 iterations for LN-Symmetry by pre-computing Tags.\n- It addresses potential length redistribution attacks and proposes a solution involving a custom hash function.\n- The solution and its technical details are available in a GitHub pull request link provided.", - "n_threads": 11, + "published_at": "2024-10-28T19:09:55.723000+00:00", + "summary": "- Eric Voskuil showed Libbitcoin's IBD is up to 15 times faster than Bitcoin Core with `-assumevalid`.\n- Libbitcoin uses an event-based, asynchronous system and a relational database structure for improved efficiency.\n- Despite advances, Libbitcoin doesn't fully implement DoS protection and faces performance benchmarks issues.", + "n_threads": 10, "dev_name": "delvingbitcoin", "contributors": [ - "1440000bytes", - "ajtowns" + "josibake", + "andrewtoth", + "evoskuil", + "instagibbs" ], - "file_path": "static/delvingbitcoin/Oct_2024/3401_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml", - "combined_summ_file_path": "static/delvingbitcoin/Oct_2024/combined_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" + "file_path": "static/delvingbitcoin/Oct_2024/3432_Libbitcoin-for-Core-people.xml", + "combined_summ_file_path": "static/delvingbitcoin/Oct_2024/combined_Libbitcoin-for-Core-people.xml" } ], "today_in_history_posts": [ { - "id": "013275", - "title": "[BIP Proposal] Buried Deployments", - "link": "https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-November/013275.html", + "id": "015292", + "title": "Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard", + "link": "https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015292.html", "authors": [ - "Suhas Daftuar" + "Johnson Lau" ], - "published_at": "2016-11-14T18:17:25+00:00", - "summary": "- Bitcoin Core has simplified consensus rules for BIPs 34, 66, and 65.\n- The simplification was documented in a BIP for historical purposes.\n- Prior soft forks used miner signaling, now replaced by caching block heights.", - "n_threads": 23, + "published_at": "2017-11-15T18:02:48+00:00", + "summary": "- Johnson Lau proposes making OP_CODESEPARATOR and FindAndDelete non-standard in non-segwit scripts.\n- He views FindAndDelete as a complex, mostly unnecessary function that segwit scripts omit.\n- A softfork could eventually remove these functions from consensus code by first making them non-standard.", + "n_threads": 5, "dev_name": "bitcoin-dev", "contributors": [ - "Eric Voskuil", - "Alex Morcos", - "Jorge Tim\u00f3n", - "Pieter Wuille", - "Btc Drak", - "Jameson Lopp", - "Luke Dashjr", - "Peter Todd", - "Thomas Kerin", - "Tier Nolan", - "Tom Zander" + "M", + "Mark Friedenbach", + "Sjors Provoost" ], - "file_path": "static/bitcoin-dev/Nov_2016/013275_-BIP-Proposal-Buried-Deployments.xml", - "combined_summ_file_path": "static/bitcoin-dev/Nov_2016/combined_-BIP-Proposal-Buried-Deployments.xml" + "file_path": "static/bitcoin-dev/Nov_2017/015292_Making-OP-CODESEPARATOR-and-FindAndDelete-in-non-segwit-scripts-non-standard.xml", + "combined_summ_file_path": "static/bitcoin-dev/Nov_2017/combined_Making-OP-CODESEPARATOR-and-FindAndDelete-in-non-segwit-scripts-non-standard.xml" }, { - "id": "000652", - "title": "LN without SegWit: less efficient or less secure?", - "link": "https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-January/000652.html", + "id": "000774", + "title": "(no subject)", + "link": "https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-November/000774.html", "authors": [ - "Andr\u00e9s G. Aragoneses" + "Mark Botley" ], - "published_at": "2017-01-14T10:17:40+00:00", - "summary": "- The email queries about SegWit activation and its impact on Lightning Network's functionality.\n- It discusses efficiency and security between levels 2 and 3 of Lightning Network.\n- The sender seeks clarification on improving level 2 security by outsourcing channel monitoring.", - "n_threads": 9, + "published_at": "2017-11-09T08:22:10+00:00", + "summary": "- Mark Botley reported a technical glitch in the email system.\n- He requested more information or context to understand the message.\n- The source of the issue was not provided in the message.", + "n_threads": 10, "dev_name": "lightning-dev", "contributors": [ - "Anthony Towns", - "Christian Decker", - "Rusty Russell", - "Stefano Pepe" + "Nongluck Loyha", + "Chris Malloy", + "D", + "Victor Umobi" ], - "file_path": "static/lightning-dev/Jan_2017/000652_LN-without-SegWit-less-efficient-or-less-secure-.xml", - "combined_summ_file_path": "static/lightning-dev/Jan_2017/combined_LN-without-SegWit-less-efficient-or-less-secure-.xml" + "file_path": "static/lightning-dev/Nov_2017/000774_-no-subject-.xml", + "combined_summ_file_path": "static/lightning-dev/Nov_2017/combined_-no-subject-.xml" }, { - "id": "62", - "title": "Thoughts on scaling and consensus changes (2023)", - "link": "https://delvingbitcoin.org/t/thoughts-on-scaling-and-consensus-changes-2023/32", + "id": "342", + "title": "Batched Splicing Considered Risky", + "link": "https://delvingbitcoin.org/t/batched-splicing-considered-risky/170", "authors": [ - "jamesob" + "ZmnSCPxj" ], - "published_at": "2023-08-16T15:22:13.243000+00:00", - "summary": "- Bitcoin scalability aims for 1 billion weekly users through 50,000 off-chain \"bitcoin banks.\"- Innovative scaling includes coinpools and federated sidechains, balancing security and affordability.\n- Tools like `OP_VAULT` and Layer 2 protocols, such as the Lightning Network, enhance scalability and security.", - "n_threads": 5, + "published_at": "2023-11-08T20:33:13.829000+00:00", + "summary": "- Splicing transactions add complexity and vulnerability, especially with arbitrary inputs and outputs for batching.\n- Malicious actors can disrupt transactions, highlighting the need for disincentives against such actions.\n- Despite potential strategies, splicing introduces significant security and operational challenges on the Lightning Network.", + "n_threads": 10, "dev_name": "delvingbitcoin", "contributors": [ - "Ajian", - "CubicEarth", - "EthnTuttle", - "jungly", - "melvincarvalho" + "ajtowns", + "Greg Sanders", + "t-bast" ], - "file_path": "static/delvingbitcoin/Aug_2023/62_Thoughts-on-scaling-and-consensus-changes-2023-.xml", - "combined_summ_file_path": "static/delvingbitcoin/Aug_2023/combined_Thoughts-on-scaling-and-consensus-changes-2023-.xml" + "file_path": "static/delvingbitcoin/Nov_2023/342_Batched-Splicing-Considered-Risky.xml", + "combined_summ_file_path": "static/delvingbitcoin/Nov_2023/combined_Batched-Splicing-Considered-Risky.xml" } ] } \ No newline at end of file diff --git a/static/homepage/Nov_2024/2024-11-06-homepage.json b/static/homepage/Nov_2024/2024-11-06-homepage.json new file mode 100644 index 000000000..294de0b32 --- /dev/null +++ b/static/homepage/Nov_2024/2024-11-06-homepage.json @@ -0,0 +1,262 @@ +{ + "header_summary": "Antoine Poinsot announced the release of new security advisories addressing historical issues in Bitcoin Core, emphasizing the project's commitment to transparent security practices. These advisories, along with a detailed disclosure policy, can be found on their [official website](https://bitcoincore.org/en/2024/11/05/cb-stall-hindering-propagation) and highlight the completion of a process initiated in July to enhance security transparency.\n\nAdam Borcany introduced an innovative approach for securing Bitcoin transactions through proof-of-work (PoW) locked outputs, offering a more granular difficulty adjustment than current methods. This novel method, bypassing the limitations of signature grinding by using a fixed set of signatures and private keys, suggests a more efficient and flexible system for transaction security, as outlined in a [detailed discussion](https://gnusha.org/pi/bitcoindev/CAOY=fzk-ksDGT_oyCKF=EJnnXaXoCbfCzxW+9PBQV=us-K=PuQ@mail.gmail.com/T/#u#m6466fc7480c6cde4dc938a788051920242c7231c).\n\nResearch highlighted by cndolo reveals potential censorship vulnerabilities within the Lightning Network, caused by the centralization of network layers and the identifiability of TCP headers. The study proposes several countermeasures, such as adaptive padding techniques and leveraging AS information in pathfinding algorithms, to enhance resistance against censorship, emphasizing the need for improved privacy and decentralization measures within the network. The full exploration of these vulnerabilities and proposed solutions is available at [Delving Bitcoin](https://delvingbitcoin.org/t/research-paper-on-ln-payment-censorship/1248).\n\nZmnSCPxj proposes the SuperScalar mechanism to address the Lightning Service Provider (LSP) Last-Mile Problem, enabling efficient and secure liquidity provisioning without blockchain consensus changes. This comprehensive solution leverages Decker-Wattenhofer channel factories, timeout trees, and pseudo-Spilman leaves to facilitate scalability, security, and decentralized liquidity management, marking a significant advancement in addressing the challenges of incoming liquidity for new users on the Lightning Network. The technical details and implications of this proposal are discussed at [Delving Bitcoin](https://delvingbitcoin.org/t/superscalar-laddered-timeout-tree-structured-decker-wattenhofer-factories-with-pseudo-spilman-leaves/1242).", + "recent_posts": [ + { + "id": "m1bab216dee18c20e39cbf90f1261a736c18cd3a1", + "title": "Public disclosure of one vulnerability affecting Bitcoin Core <26.0", + "link": "https://gnusha.org/pi/bitcoindev/uJpfg8UeMOfVUATG4YRiGmyz5MALtZq68FCBXA6PT-BNstodivpqQfDxD1JAv5Qny_vuNr-A1m8jIDNHQLhAQt8hj8Ee9OT6ZFE5Z16O97A=@protonmail.com/T/#u#m1bab216dee18c20e39cbf90f1261a736c18cd3a1", + "authors": [ + "Antoine Poinsot" + ], + "published_at": "2024-11-05T16:00:00+00:00", + "summary": "- The latest Bitcoin Core security advisories are available on their official website.\n- New vulnerabilities will follow a publicly advertised disclosure policy henceforth.\n- This signifies the project's drive for transparent and responsible security practices.", + "n_threads": 0, + "dev_name": "bitcoin-dev", + "contributors": [], + "file_path": "static/bitcoin-dev/Nov_2024/m1bab216dee18c20e39cbf90f1261a736c18cd3a1_Public-disclosure-of-one-vulnerability-affecting-Bitcoin-Core-26-0.xml", + "combined_summ_file_path": "" + }, + { + "id": "m6466fc7480c6cde4dc938a788051920242c7231c", + "title": "Bitcoin PoW locked outputs with arbitrary difficulty", + "link": "https://gnusha.org/pi/bitcoindev/CAOY=fzk-ksDGT_oyCKF=EJnnXaXoCbfCzxW+9PBQV=us-K=PuQ@mail.gmail.com/T/#u#m6466fc7480c6cde4dc938a788051920242c7231c", + "authors": [ + "Adam Borcany" + ], + "published_at": "2024-11-04T15:34:00+00:00", + "summary": "- Adam Borcany discusses a new Bitcoin transaction security method beyond signature grinding.\n- This method allows flexible difficulty adjustments using mathematical intervals, not relying on elliptic calculations.\n- It proposes a practical application with Node.JS, enhancing the security and adaptability of PoW-locked outputs.", + "n_threads": 0, + "dev_name": "bitcoin-dev", + "contributors": [], + "file_path": "static/bitcoin-dev/Nov_2024/m6466fc7480c6cde4dc938a788051920242c7231c_Bitcoin-PoW-locked-outputs-with-arbitrary-difficulty.xml", + "combined_summ_file_path": "" + }, + { + "id": "3490", + "title": "Research Paper on LN Payment Censorship", + "link": "https://delvingbitcoin.org/t/research-paper-on-ln-payment-censorship/1248", + "authors": [ + "cndolo" + ], + "published_at": "2024-11-05T11:57:11.703000+00:00", + "summary": "- Recent research highlights Lightning Network's vulnerability to censorship by network-level adversaries. - It details how attackers could manipulate LN transactions without detection by exploiting network centralization. - Proposed countermeasures include adaptive padding and incorporating AS information into pathfinding to improve resilience.", + "n_threads": 0, + "dev_name": "delvingbitcoin", + "contributors": [], + "file_path": "static/delvingbitcoin/Nov_2024/3490_Research-Paper-on-LN-Payment-Censorship.xml", + "combined_summ_file_path": "" + }, + { + "id": "3488", + "title": "A Fast, Scalable Protocol For Resolving Lightning Payments", + "link": "https://delvingbitcoin.org/t/a-fast-scalable-protocol-for-resolving-lightning-payments/1233/3", + "authors": [ + "harding" + ], + "published_at": "2024-11-05T10:14:19.731000+00:00", + "summary": "- The article analyzes vulnerabilities in the Offchain Payment Routing system, focusing on exploitable free probes.\n- It suggests incremental routing fee increases to cover losses from node failures, though costs could rise significantly.\n- It explores probabilistic payments as a scalable workaround for high HTLC settlement costs, noting limited progress.", + "n_threads": 2, + "dev_name": "delvingbitcoin", + "contributors": [ + "JohnLaw", + "morehouse" + ], + "file_path": "static/delvingbitcoin/Nov_2024/3488_A-Fast-Scalable-Protocol-For-Resolving-Lightning-Payments.xml", + "combined_summ_file_path": "static/delvingbitcoin/Nov_2024/combined_A-Fast-Scalable-Protocol-For-Resolving-Lightning-Payments.xml" + }, + { + "id": "3469", + "title": "SuperScalar: Laddered Timeout-Tree-Structured Decker-Wattenhofer Factories With Pseudo-Spilman Leaves", + "link": "https://delvingbitcoin.org/t/superscalar-laddered-timeout-tree-structured-decker-wattenhofer-factories-with-pseudo-spilman-leaves/1242", + "authors": [ + "ZmnSCPxj" + ], + "published_at": "2024-11-04T15:40:11.090000+00:00", + "summary": "- SuperScalar aims to resolve the Bitcoin Lightning Network's liquidity issues securely and efficiently.\n- It employs advanced mechanisms like Decker-Wattenhofer and pseudo-Spilman channel factories for scalability.\n- This construction ensures safety, prevents misuse by LSPs, and encourages user and network integrity.", + "n_threads": 0, + "dev_name": "delvingbitcoin", + "contributors": [], + "file_path": "static/delvingbitcoin/Nov_2024/3469_SuperScalar-Laddered-Timeout-Tree-Structured-Decker-Wattenhofer-Factories-With-Pseudo-Spilman-Leaves.xml", + "combined_summ_file_path": "" + } + ], + "active_posts": [ + { + "id": "mb513065fc5985f1a474e7537ca7720288d8f9579", + "title": "libsecp256k1 v0.6.0 released", + "link": "https://gnusha.org/pi/bitcoindev/f96dfed1-4185-42c2-ae71-738255da005e@gmail.com/T/#u#mb513065fc5985f1a474e7537ca7720288d8f9579", + "authors": [ + "Jonas Nick" + ], + "published_at": "2024-11-04T17:45:00+00:00", + "summary": "- The latest version 0.6.0 of libsecp256k1 introduces several updates and improvements.\n- It features a MuSig2 module and a method for more secure clearing of secrets.\n- Unused secp256k1_scratch_space functions were removed, streamlining the library.", + "n_threads": 0, + "dev_name": "bitcoin-dev", + "contributors": [], + "file_path": "static/bitcoin-dev/Nov_2024/mb513065fc5985f1a474e7537ca7720288d8f9579_libsecp256k1-v0-6-0-released.xml", + "combined_summ_file_path": "" + }, + { + "id": "m0927acdfbd44f01a5509d914c9d12e44f95fe033", + "title": "File Format for Wallet Inheritance and Recovery", + "link": "https://gnusha.org/pi/bitcoindev/4c51d18b-2444-4939-8f12-d0abe6d11e20n@googlegroups.com/T/#u#m0927acdfbd44f01a5509d914c9d12e44f95fe033", + "authors": [ + "Robert Netzke" + ], + "published_at": "2024-11-04T18:29:00+00:00", + "summary": "- Robert Netzke introduces a file format for easy Bitcoin wallet descriptor recovery.\n- The format aids inheritance, inter-service interoperability, and simplifies backups.\n- Feedback is sought for refining the approach and its practical implementation.", + "n_threads": 0, + "dev_name": "bitcoin-dev", + "contributors": [], + "file_path": "static/bitcoin-dev/Nov_2024/m0927acdfbd44f01a5509d914c9d12e44f95fe033_File-Format-for-Wallet-Inheritance-and-Recovery.xml", + "combined_summ_file_path": "" + }, + { + "id": "mdabc1118c9d2fe5e0e777e50d77308aa3fab2c41", + "title": "Bitcoin Core 27.2 released", + "link": "https://gnusha.org/pi/bitcoindev/CAFyhPjWx0qSuBgBqboxWwWjkFZPbsWrEx8sW0Me8=kXQRppbbg@mail.gmail.com/T/#u#mdabc1118c9d2fe5e0e777e50d77308aa3fab2c41", + "authors": [ + "Michael Ford" + ], + "published_at": "2024-11-04T13:06:00+00:00", + "summary": "- Bitcoin Core version 27.2 has been released, featuring bug fixes and performance enhancements.\n- Users can download the new version from the official website or via BitTorrent.\n- The update supports older wallet versions and has been tested on several operating systems.", + "n_threads": 0, + "dev_name": "bitcoin-dev", + "contributors": [], + "file_path": "static/bitcoin-dev/Nov_2024/mdabc1118c9d2fe5e0e777e50d77308aa3fab2c41_Bitcoin-Core-27-2-released.xml", + "combined_summ_file_path": "" + }, + { + "id": "1996", + "title": "Great Consensus Cleanup Revival", + "link": "https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710", + "authors": [ + "AntoineP" + ], + "published_at": "2024-03-24T19:53:27.073000+00:00", + "summary": "- The analysis suggests improvements in the Bitcoin protocol to enhance security and efficiency.\n- It proposes solutions for vulnerabilities like the timewarp exploit and inefficient block validation.\n- Community debate surrounds certain suggestions, reflecting concerns over network scalability and functionality.", + "n_threads": 46, + "dev_name": "delvingbitcoin", + "contributors": [ + "ajtowns", + "evoskuil", + "David Harding", + "sjors", + "MattCorallo", + "recent798", + "1440000bytes", + "ariard", + "benthecarman", + "kcalvinalvin", + "plebhash" + ], + "file_path": "static/delvingbitcoin/March_2024/1996_Great-Consensus-Cleanup-Revival.xml", + "combined_summ_file_path": "static/delvingbitcoin/March_2024/combined_Great-Consensus-Cleanup-Revival.xml" + }, + { + "id": "989", + "title": "LNHANCE bips and implementation", + "link": "https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376", + "authors": [ + "reardencode" + ], + "published_at": "2024-01-07T18:41:08.593000+00:00", + "summary": "- Recent Bitcoin protocol updates propose features enhancing Lightning Network capabilities.\n- Proposed changes include BIP119 and new opcodes, aiming to introduce output restricting covenants.\n- These enhancements could improve Bitcoin's scalability, privacy, and utility significantly.", + "n_threads": 17, + "dev_name": "delvingbitcoin", + "contributors": [ + "moonsettler", + "michaelfolkson", + "Greg Sanders", + "RubenSomsen", + "ZmnSCPxj", + "alex", + "cryptoquick", + "hampus", + "urza" + ], + "file_path": "static/delvingbitcoin/Jan_2024/989_LNHANCE-bips-and-implementation.xml", + "combined_summ_file_path": "static/delvingbitcoin/Jan_2024/combined_LNHANCE-bips-and-implementation.xml" + }, + { + "id": "3432", + "title": "Libbitcoin for Core people", + "link": "https://delvingbitcoin.org/t/libbitcoin-for-core-people/1222", + "authors": [ + "AntoineP" + ], + "published_at": "2024-10-28T19:09:55.723000+00:00", + "summary": "- Eric Voskuil showed Libbitcoin's IBD is up to 15 times faster than Bitcoin Core with `-assumevalid`.\n- Libbitcoin uses an event-based, asynchronous system and a relational database structure for improved efficiency.\n- Despite advances, Libbitcoin doesn't fully implement DoS protection and faces performance benchmarks issues.", + "n_threads": 10, + "dev_name": "delvingbitcoin", + "contributors": [ + "josibake", + "andrewtoth", + "evoskuil", + "instagibbs" + ], + "file_path": "static/delvingbitcoin/Oct_2024/3432_Libbitcoin-for-Core-people.xml", + "combined_summ_file_path": "static/delvingbitcoin/Oct_2024/combined_Libbitcoin-for-Core-people.xml" + } + ], + "today_in_history_posts": [ + { + "id": "015292", + "title": "Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard", + "link": "https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015292.html", + "authors": [ + "Johnson Lau" + ], + "published_at": "2017-11-15T18:02:48+00:00", + "summary": "- Johnson Lau proposes making OP_CODESEPARATOR and FindAndDelete non-standard in non-segwit scripts.\n- He views FindAndDelete as a complex, mostly unnecessary function that segwit scripts omit.\n- A softfork could eventually remove these functions from consensus code by first making them non-standard.", + "n_threads": 5, + "dev_name": "bitcoin-dev", + "contributors": [ + "M", + "Mark Friedenbach", + "Sjors Provoost" + ], + "file_path": "static/bitcoin-dev/Nov_2017/015292_Making-OP-CODESEPARATOR-and-FindAndDelete-in-non-segwit-scripts-non-standard.xml", + "combined_summ_file_path": "static/bitcoin-dev/Nov_2017/combined_Making-OP-CODESEPARATOR-and-FindAndDelete-in-non-segwit-scripts-non-standard.xml" + }, + { + "id": "000774", + "title": "(no subject)", + "link": "https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-November/000774.html", + "authors": [ + "Mark Botley" + ], + "published_at": "2017-11-09T08:22:10+00:00", + "summary": "- Mark Botley reported a technical glitch in the email system.\n- He requested more information or context to understand the message.\n- The source of the issue was not provided in the message.", + "n_threads": 10, + "dev_name": "lightning-dev", + "contributors": [ + "Nongluck Loyha", + "Chris Malloy", + "D", + "Victor Umobi" + ], + "file_path": "static/lightning-dev/Nov_2017/000774_-no-subject-.xml", + "combined_summ_file_path": "static/lightning-dev/Nov_2017/combined_-no-subject-.xml" + }, + { + "id": "342", + "title": "Batched Splicing Considered Risky", + "link": "https://delvingbitcoin.org/t/batched-splicing-considered-risky/170", + "authors": [ + "ZmnSCPxj" + ], + "published_at": "2023-11-08T20:33:13.829000+00:00", + "summary": "- Splicing transactions add complexity and vulnerability, especially with arbitrary inputs and outputs for batching.\n- Malicious actors can disrupt transactions, highlighting the need for disincentives against such actions.\n- Despite potential strategies, splicing introduces significant security and operational challenges on the Lightning Network.", + "n_threads": 10, + "dev_name": "delvingbitcoin", + "contributors": [ + "ajtowns", + "Greg Sanders", + "t-bast" + ], + "file_path": "static/delvingbitcoin/Nov_2023/342_Batched-Splicing-Considered-Risky.xml", + "combined_summ_file_path": "static/delvingbitcoin/Nov_2023/combined_Batched-Splicing-Considered-Risky.xml" + } + ] +} \ No newline at end of file