Removing channel reserve for mobile wallet users

The sender suggests adding this feature through a Blip and mentions the usefulness of including information on how to prove possible cheating attacks in the spec/blip. They also inquire about reporting an issue related to the behavior of non-custodial wallets.

The email addresses the assumption regarding non-custodial wallets' ability to react to revoked commitments. It emphasizes the importance of the "to_self_delay" parameter and suggests that mobile wallets should run background jobs to perform checks and notify users. The sender also mentions that removing the reserve requirement eliminates the need for a distinction between different outputs and explains that negotiating 0-reserve is as simple as setting a feature bit or adding a TLV to existing messages.

The main concern discussed in the email is the lack of reserve for Lightning Service Providers (LSPs), which makes it easier for them to steal since the offline concern is on the mobile user. The sender also mentions the absence of reliable watch tower integrations/products to mitigate this issue. They question how a user can publish a previous commitment and whether this is something that should be solved for and exposed to users. The email includes a link to the dust reserves that still apply.

The email provides detailed information on how a wallet user can prove certain actions and information related to their wallet provider. It outlines four points that can be proven, including the occurrence of a revocation, the user being one of the participants, the wallet provider being the other participant, and identifying the cheating counterparty. The sender highlights the key insight regarding the private channel_update that can be shown.

Bastien's email discusses the current state of wallets in Phoenix and proposes a change to the reserve requirements for Lightning Service Providers (LSPs). Bastien argues for removing the reserve requirement for LSPs without compromising trust, highlighting the difference between routing nodes and wallet users in terms of their relationship with service providers. The email ends with a question regarding the "dust reserve limit."

In response to Bastien's message, Tony raises questions and seeks clarifications regarding the proposed user experience (UX) for wallets and Lightning Service Providers (LSPs). Tony asks if the proposal suggests a network-wide switch away from reserves or only applies to specific types of wallets and LSPs. He also seeks further information or clarification on the dust reserve limit.

The email discusses the purpose and drawbacks of the channel reserve requirement for channels between mobile wallet users and their service providers. It highlights the importance of the reserve for routing nodes but argues that it becomes a scalability problem for wallet providers. The email points out the capital efficiency and user experience issues associated with the channel reserve. It suggests removing the reserve on both sides for mobile wallet users and their service providers, explaining the risks and trade-offs involved. The email draws parallels between LN-penalty without channel reserves and LN-symmetry (Eltoo) in terms of cheating scenarios and on-chain fees.