Posted by Bastien TEINTURIER
Oct 18, 2023/13:51 UTC
The email discusses the idea of getting rid of the channel reserve requirement for channels between mobile wallet users and their service providers. The channel reserve requirement ensures that both peers always have an output in the commit transaction, which has two important consequences. First, if a malicious node publishes a revoked commitment, they will risk losing money because the honest node can claim the funds. Second, nodes are disincentivized from force-closing channels because they would need to pay on-chain fees to get their funds back.The author believes that these properties are important for channels between normal routing nodes that don't provide paid services to each other. However, there are drawbacks to having a channel reserve. One drawback is capital efficiency because the reserve represents unused liquidity. For routing nodes, this may not be an issue as they actively manage their channels. But for wallet providers, who need to keep at least one channel open with each user, it becomes a scalability problem.Another drawback is the user experience (UX). Users look at their channel state to determine how much they can receive off-chain. It becomes difficult to explain why there is a large gap between what they think they should be able to receive and what they actually can receive.In the specific setting of channels between mobile wallet users and their service providers, the author argues that it is acceptable to remove the channel reserve on both sides. The service provider pays the on-chain fees for the commit transaction, even if they don't have an output in the transaction. This means they still lose something if they publish a revoked commit transaction. The wallet user can still get their funds back using penalty transactions, which doesn't cost them more than normal second-stage transactions. The service provider cannot steal funds but can grief their users, at the cost of paying on-chain fees and missing out on future routing fees. The wallet user can publicly show that the service provider published a revoked commitment, which can damage their reputation.Removing the reserve on the wallet user's side is a risk that the wallet provider takes to ensure a good user experience. The griefing amount is limited, and the user has already paid fees to the wallet provider before reaching that state. This trade-off is considered acceptable for service providers. Additionally, it can be argued that LN-penalty without channel reserves is similar to LN-symmetry (Eltoo), where a cheating node can always publish a previous commitment, and the honest node can replay the latest state on top of that commitment. In this case, when the service provider tries to cheat, they pay the on-chain fees for the commit transaction, similar to Eltoo.Overall, the email presents an argument for removing the channel reserve requirement for channels between mobile wallet users and their service providers, highlighting the benefits and addressing potential concerns.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback