Published on: 2018-08-27T13:22:49+00:00
The Lightning-dev community recently discussed the implementation of splice in and out features for the Lightning Network. Two methods were proposed: broadcasting a spend to join random outputs and maintaining both old and new channels until confirmation, or pre-committing with another funding transaction and joining channels once confirmed. The second option requires two on-chain transactions, leading to a preference for the first option. For version 1.1, it was suggested to allow only one concurrent change at a time to reduce complexity.However, extending the gossip protocol for these features presents challenges. Extending channel_announce would not propagate through old nodes until the new channel is six deep, and extending channel_update would not propagate after the new spend is seen on the Bitcoin network. A new message type would not propagate at all through old nodes. It may be possible to make the "splice information" signatures + old-chanid discardable.In terms of implementation, a generic message for both splice in/out should be included, allowing both sides to schedule and queue up possible changes. The priority should be given to Atomic Multi-Path (AMP) payments, which retain proper Zero Knowledge Contingent Payment (ZKCP). With AMP, the size of channels becomes less important. On-to-offchain and off-to-onchain bridges form a different layer, reducing the necessity for dual-funded channels.Overall, the discussions within the Lightning-dev community highlighted the importance of splicing and AMP for improving user experience. However, the implementation of these features and the extension of the gossip protocol present challenges that need to be addressed.In an email exchange between Laolu and ZmnSCPxj, they discuss the technical implementation of a splicing proposal for the Lightning Network. The proposal aims to include a generic message for both splice in/out, allowing both sides to schedule/queue up possible changes. The goal is to achieve fully async splice in/out to improve user experience by avoiding the need to block channel operation for confirmations. In addition, a pre-announcement gossip message would signal other nodes that the channel is about to change outpoints but can still be used for routing.However, there are some considerations to address. One issue is that during the transition period, there will be a few blocks where other nodes may consider the channel closed while the replacement channel is not yet deep enough on-chain to be re-announced. To mitigate this, it is suggested to limit Splice-in if it has not been sufficiently buried in the chain.The Lightning Network developers are actively working on splicing, a protocol modification that requires deep knowledge of Bitcoin's protocol and specific implementation details. This is in contrast to modifying autopilot strategies, which is purely policy-based. It is expected that splicing will be included in BOLT 1.1, with the official draft planned for later this year. However, implementations can already draft working versions and reserve a temporary feature bit.To streamline operations, a "scheduler" for splicing can be included in the proposal, allowing implementations to batch their operations efficiently. The discussions on splicing took place at the 2nd lightninghackday in Berlin, where attendees engaged in intensive conversations about the autopilot feature and splicing. Developers from Lightning Labs informed attendees that they were currently working on splicing. While the technical aspects seem straightforward, formalizing the protocols is necessary.The author of the email found a six-month-old post mentioning a plan to include a splicing protocol in BOLT 1.1. However, upon checking the git repository and issues, they did not find any ongoing work or inclusion of the protocol. As a result, they are considering taking the initiative on the topic over the next few weeks if no one else is working on it, or offering support to anyone who is. The author believes that splicing should be a higher priority than improving the intelligence of the autopilot feature and suggests specifying the process in the Lightning RFC.The author seeks assistance in improving the quality of the specification they will create for splicing, as this is their first time contributing to such a formal RFC.
Updated on: 2023-07-31T20:20:03.463716+00:00