Removing channel reserve for mobile wallet users

The email discusses the assumption that non-custodial wallets are unable to react to revoked commitments. The sender emphasizes that if this assumption is made, there are already trust model issues present. The important parameter to consider is the "to_self_delay" which is typically set to two weeks. It is mentioned that the phone only needs to be online once every two weeks to detect and react to the revoked commit. Mobile wallets should run frequent background jobs to perform these checks and notify the user if they have been unable to run the checks due to limited CPU time. This is what Phoenix does.The sender also mentions that removing the reserve requirement eliminates the need for a distinction between different outputs. There will always be at least one output since the channel total capacity remains greater than dust. This distinction is not new and does not complicate the protocol. The sender states that negotiating 0-reserve is as simple as setting a feature bit or adding a TLV (Type-Length-Value) to existing messages.In conclusion, the email addresses the assumption regarding non-custodial wallets' ability to react to revoked commitments. It highlights the importance of the "to_self_delay" parameter and suggests that mobile wallets should run background jobs to perform checks and notify users. Furthermore, it discusses the removal of the reserve requirement and the simplicity of negotiating 0-reserve.