Removing channel reserve for mobile wallet users

The email exchange discusses the topic of non-custodial wallets and their ability to react to revoked commitments. The sender mentions that if someone assumes their non-custodial wallet cannot react to revoked commitments, it indicates other trust-related issues in their model. The important parameter in this context is the to_self_delay parameter, which is typically set to two weeks. The sender explains that the phone only needs to be online once every two weeks to detect and respond to revoked commits. Mobile wallets should run frequent background jobs to perform these checks and notify the user if there are any issues with CPU time. This behavior is implemented in Phoenix.

The sender then clarifies that the information provided so far does not apply to the removal of the reserve requirement. In this scenario, there will always be at least one output since the channel's total capacity remains greater than dust. The sender states that this distinction already exists in the current protocol and does not add any complications. They also mention that negotiating 0-reserve can be done easily by setting a feature bit or adding a TLV (Type-Length-Value) to existing messages.

In conclusion, the sender emphasizes that the ability of non-custodial wallets to react to revoked commitments is not a significant concern and can be addressed effectively through the to_self_delay parameter and background checks. Additionally, they highlight that removing the reserve requirement does not introduce new complexities to the protocol.