Published on: 2017-05-09T09:56:20+00:00
The discussion focuses on the possibility of using onion routes with on-chain and off-chain hops for exchanges. It addresses the issue of chicken-and-egg problems when trying to receive Litecoin via Lightning without having LTC to initiate a channel on the LTC side. The current 1.0 spec requires the initiator to fund the channel, but there is no explicit reason why this is necessary. Allowing onion routes to start and end on-chain can simplify the process and protect against bad actors.A proposal for a new operation called re-anchoring in the Lightning Network protocol has been discussed. This method allows for adding or removing funds from a channel by mutual cooperation and forgetting older commitment transactions. Initially, there were considerations for a splice-in/splice-out/reanchoring scheme, but it was deemed more complex. It was agreed that if the funding transaction only outputs, it's acceptable, but if it inputs, a pre-splice-in transaction is needed before safely making the re-anchoring transaction "floating". Christian Decker commended the elegance of this proposal.The conversation delves into the functioning of onion-routing mechanisms in the Lightning Network. Side funds do not impact the settled channel state, and splice-in and splice-out operations are discussed as methods for controlling channel capacity. There is also a contingency plan in case Bitcoin cannot deploy a malleability fix in two years. Risks associated with uncooperative nodes and the interaction between CSV and CLTV in commitment transaction timeouts and HTLCs are explored. The top-up proposal is considered, which allows someone off-LN to pay into an LN node without committing funds to open a channel. The conversation concludes with a discussion on how Alice can expedite payments by opening channels to well-connected nodes before launching her new business.ZmnSCPxj proposes a top-up mechanism in the Lightning Network that utilizes onion routing with an on-chain transaction. This allows Alice to add funds to her side of the channel without affecting the channel state or keeping track of side funds. Another proposal called splice-in/-out is suggested to solve the top-up problem by closing and reopening a channel right from the settlement. However, there are risks involved in this approach, such as potential hostage situations. Christian Decker suggests exploring feedback and comparisons between the two proposals. The top-up procedure could also be used as the first hop of an onion route for someone off-LN to pay into an LN node without committing funds to open a channel.Christian Decker presents the splice-in/-out mechanism as a solution to topping up funds in a channel. This method involves creating a new 2-of-2 output and allowing it to confirm before collaborating with the counterparty to close the channel and open a new one. The settlement transaction becomes the funding transaction of the new channel, eliminating the need for confirmation. Feedback and comparisons with another proposal are sought. The discussion also mentions the possibility of using the top-up system to pay for services in micropayment channels.The Lightning Network protocol could potentially be expanded with a top-up system proposed by ZmnSCPxj. This system allows users to add funds to a micropayment channel for service payments. The procedure involves generating a preimage, proposing a top-up operation, creating an HTLC transaction, and broadcasting it to the Bitcoin network. Once confirmed, the transaction ID and preimage hash are exchanged, enabling Lightning payments.
Updated on: 2023-07-31T19:19:52.991438+00:00