Published on: 2018-11-07T06:06:07+00:00
In a recent email exchange, ZmnSCPxj expressed concern about removing the initiator distinction in certain actions within the Lightning Network. ZmnSCPxj believes that the initiator of an action should be the one to pay any costs or fees related to that action. For example, in opening a channel, the channel opener pays for all on-chain fees related to opening and closing the channel. This approach reduces the potential for attacks and deters most attackers.Olaoluwa Osuntokun and Christian Decker have different opinions on creating multiple channels to a single peer or increasing capacity with a specific peer. Osuntokun believes that it becomes less like a network and more like channels to specific big businesses. However, Decker argues that having multiple channels allows for sending larger amounts of BTC and accommodating increased HTLC bandwidth load. It is important to maintain a diverse set of channels for fault tolerance, path diversity, and redundancy reasons.Olaoluwa Osuntokun and Rusty Russell discussed the limitations of their descriptor language in the context of splicing inputs in a non-blocking way. They also talked about the idea of using CPFP (Child Pays For Parent) to anchor down splicing transactions. The conversation includes discussions on nested P2SH inputs, maintaining CSV, and optional fields.The conversation between Laolu and ZmnSCPxj revolves around the Lightning Network and its protocol. Laolu emphasizes the utility of having multiple channels to a given peer. They also discuss the initiator distinction and the prioritization of work items. The conversation also touches on lifting the "pre-seating of inputs" and the potential risks involved.The Lightning developers have proposed a design for the splice feature, which would allow nodes to add or remove liquidity from channels without closing them. The proposal includes a distinct message for pending splices and suggests allowing both parties to modify parameters as the size of the channel changes. The developers have also discussed the race condition between a unilateral close and the re-anchoring commitment transaction, as well as scalability issues with increasing maximum values.The Lightning Network community is exploring the implementation of splicing channels with desired properties. The proposal suggests sending a distinct message referencing the active channel ID and a splice channel ID for pending splices. The discussion includes topics such as channel updates, Shachain, multiple funding outputs, and pre-seating inputs.The Lightning Network is discussing modifications to the `revoke_and_ack` or `channel_reestablish` messages. The proposed modifications would apply the commitment secrets/points to the current channel and any pending splices. The network is also considering using Taproot address or publicly derivable address specific to the channel to ensure both parties cooperate to spend.The conversation discusses the implications of having multiple funding TXOs for a single channel in splice proposals. The participants suggest using a static or publicly derivable address specific to the channel to refund funds if the splice isn't successful.The email exchange between Lisa Neigut and Rusty Russell on the Lightning-dev mailing list discusses the potential race condition between a unilateral close and the re-anchoring commitment transaction. Various solutions are suggested, but no suitable workaround is found.The Lightning Network is discussing modifications to the `revoke_and_ack` or `channel_reestablish` messages. The proposed modifications would apply the commitment secrets/points to the current channel and any pending splices. The network is also considering using Shachain and allowing both parties to modify parameters based on the expanding or contracting of the channel.The conversation delves into the details of the splicing protocol for Lightning Network channels. The protocol involves old and new funding outputs, old and new commitment transactions, and spliced inputs. Steps for the Splice Preparation Protocol are discussed, along with failure modes and possible scenarios. An alternative approach to the current proposal is also suggested.The article explores the safety of Lightning protocol transactions, which are not on any block and use 0-conf transactions. The Lightning protocol prevents transaction replacement, making it safe to use. However, concerns are raised about the safety of commitment transactions in certain scenarios.The email thread discusses the safety and implications of splicing in Lightning Network channels. It is noted that splice proposals can be risky due to the possibility of old commitment transactions being replaced with new ones, risking loss of collateral. The potential race condition when accepting HTLCs for the new balance after a parallel commitment is made but before the re-anchor is buried is also discussed, highlighting the need for a wait time to avoid unilateral close or revoked commitment transactions.Rusty Russell proposes a new protocol for side splice-in that treats splice-in and splice-out the same. The protocol involves preparing an output with a specific script form, checking the blockheight, and sending update_splice_in_accept once certain conditions are met. This new protocol eliminates the need for wait time.
Updated on: 2023-07-31T20:30:53.701979+00:00