Removing channel reserve for mobile wallet users

However, with the proposed protocol update, this requirement will need to be modified. The sender expresses anticipation for the Blip, which is likely a reference to an upcoming communication or announcement related to the protocol update.

Ziggie has requested Bastien to open a pull request (PR) to the bLIP repository. It is unclear what the statement "it doesn't work currently without it" refers to. There is a question regarding whether this is an issue specific to the implementation. Bastien suggests that if the channel reserve is removed, then there would be no need to consider the dust limit.

The sender expresses support for introducing the 0-channel reserve option into the protocol. They suggest adding it via a Blip and mention that it would be useful to have the option to open zero-reserve channels. They also propose restricting this feature through a channel interceptor. The sender suggests including information on how to prove possible cheating attacks in the spec/blip. They ask if the recipient has already reported the issue.

There is a conversation between Tony and Kulpreet regarding the non-custodial wallet's ability to react to revoked commitments. Tony mentions that the important delay is the to_self_delay parameter, which is usually set to two weeks. He explains that the phone only needs to be online once every two weeks to detect the revoked commit and react to it. Mobile wallets should run frequent background jobs to perform these checks and notify the user if they've been unable to get enough CPU time to run those checks. Tony also clarifies that this discussion becomes irrelevant when removing the reserve requirement because there will always be at least one output since the channel total capacity stays greater than dust. This doesn't add anything new as this distinction already exists today and doesn't add any complication to the protocol.

John Carvalho, CEO of Synonym.to, mentions that they recently removed the reserve for their users in Bitkit, down to the dust limit. After learning more about it and the reasoning behind the reserve, they realized the design is nonsensical. They fully support Bastien's suggestion for more practical and user-friendly approaches as the reserve balance causes customer support issues and confusing UX.

Bastien acknowledges the concerns raised about the Lightning Service Provider (LSP) not keeping a reserve, stating that it's easier for them to steal since the offline concern is on the mobile user. He mentions that there are no reliable watch tower integrations/products yet to mitigate this. Tony asks if users should also be able to publish a previous commitment to solve this issue and shares a link to the GitHub repository where dust reserves still apply.

Bastien responds to Tony, explaining that in Phoenix (a wallet), they've allowed the wallet user to have no reserve but require the LSP to meet the usual reserve requirements. He argues that the channel reserve is useful between routing nodes because they don't have a "service provider" relationship, so there is more incentive to always try cheating. He suggests removing the reserve between wallet users and their LSP, partly because LSPs are not anonymous nodes who don't care about their reputation. Tony asks for clarification on whether the proposal includes removing the 1% reserve requirement network-wide or just between mobile wallets and LSPs if they opt-in. He also mentions the dust reserve limit.

Bastien starts a discussion by arguing for the removal of the channel reserve requirement for channels between mobile wallet users and their service provider. He acknowledges that the first reaction may be resistance due to it being a security parameter. However, he explains that the current design has drawbacks such as capital efficiency and user experience issues. He believes that removing the reserve on both sides can still maintain security through penalty transactions and reputation-based accountability. He also compares the proposed approach to LN-symmetry (Eltoo) and argues that if it's acceptable for Eltoo, it should be considered here as well.

In summary, the email covers discussions about the review of an implementation, the proposal to introduce the 0-channel reserve option, concerns about the LSP not keeping a reserve, and arguments for removing the channel reserve requirement between mobile wallet users and their service provider. The sender emphasizes the need for practical and user-friendly approaches while addressing security concerns through penalty transactions and reputation-based accountability.