Watchtower-Free Lightning Channels For Casual Users [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2022-11-02T16:37:36+00:00


Summary:

In a recent conversation between Bastien Teinturier and John, they discussed the current limitations of the Lightning protocol. One limitation is that a dedicated user (DLU) can only move liquidity to another Lightning channel by either getting the casual user (CLU) to sign a cooperative close transaction or putting a non-cooperative close transaction on-chain and waiting approximately two weeks before moving the liquidity. To address this limitation, LSPs are proposing a mechanism similar to splicing that allows mobile users to pre-sign a transaction that keeps the channel open but lets the LSP get their balance out non-interactively. The proposed mechanism is a trade-off where lower fees are charged for liquidity, but users have to check the blockchain regularly.Bastien also discussed the use of a pre-signed "splice" transaction that allows the dedicated user to obtain some of their capital, creating a trade-off between the dedicated user's capital efficiency and the casual user's ability to be offline for an extended period. John suggested changing the protocol so that the casual user always checks in with the dedicated user whenever they check the blockchain. This approach has its advantages in terms of capital efficiency, but it also has potential disadvantages, such as requiring the casual user to stay online long enough to complete the roundtrip of sending a check-in message to the dedicated user, getting the splice message to sign, signing it, and sending the signature back to the dedicated user.The email conversation between Bastien and John regarding the Watchtower-Free (WF) protocol has been shared on GitHub in Pull Request 863. John has proposed removing the intermediate HTLC-timeout transaction for outgoing payments, which could simplify transactions by reducing the complexity needed to ensure that a failing/malicious downstream channel does not negatively impact honest upstream channels when relaying payments. However, Bastien criticizes the proposal, stating that liquidity is not free and that DLUs must be able to quickly move liquidity from where it is unused to where it may be better used. With the WF protocol, DLUs would need to charge CLUs for the loss of expected revenue, which could be prohibitively expensive for most CLUs.John responds by outlining his understanding of the current Lightning protocol and how DLUs can only move liquidity to another Lightning channel by getting the CLU to sign a cooperative close transaction or putting a non-cooperative close transaction on-chain and waiting approximately two weeks. In contrast, with the WF protocol, the DLU could only move liquidity to another Lightning channel by either getting the CLU to sign a cooperative close transaction or putting a non-cooperative close transaction on-chain and waiting approximately one to three months before moving the liquidity. John suggests that refunding the remaining portion of CLU's cost-of-capital pre-payment to the CLU could make up for this delay, and believes that the long-term cost-of-capital charges should be very low due to bitcoin being an inherently deflationary monetary unit.Bastien thanks John for sharing the proposal and also for the inherited IDs proposal. The conversation also includes links to related proposals on GitHub and Peerswap.dev. Another email exchange discusses the comparison between the Watchtower-Free (WF) protocol and non-cooperative close transaction on-chain with a 2-week delay. The WF protocol has a larger delay of about 1-3 months, but it allows the DLU to move liquidity to another Lightning channel by either getting the CLU to sign a cooperative close transaction or putting a non-cooperative close transaction on-chain. It was suggested that in case 1), the DLU should refund the remaining portion of the CLU's cost-of-capital pre-payment, as that capital is now being made available to the DLU. The only disadvantage of the WF protocol seems to be the larger delay, but the long term cost-of-capital charges are expected to be very low due to the inherently deflationary nature of bitcoin. The email also includes links to related proposals on GitHub and Peerswap.dev.John and Bastien, two Lightning Network experts, had a discussion about the trade-offs between dedicated users (DLUs) and casual users (CLUs) in terms of capital efficiency. In the current protocol, DLUs can only move liquidity by either getting CLUs to sign a cooperative close transaction or waiting for approximately 2 weeks based on the to_self_delay parameter set by the CLU. To improve this process, the Lightning Network team is considering allowing DLUs to pre-sign a splice transaction that keeps the channel open but allows them to get their balance out non-interactively, similar to splicing.However, John proposed an alternative solution where the CLU always checks in with the DLU whenever they check the blockchain. During this check-in, if the DLU wants to splice out some channel funds, they send the CLU a splice transaction which splices out some of the funds to the DLU without requiring a to_self delay.


Updated on: 2023-08-01T00:44:12.660307+00:00