Author: Bastien TEINTURIER 2023-08-17 14:20:38+00:00
Published on: 2023-08-17T14:20:38+00:00
In the email, the sender discusses the feasibility of wallet providers attempting to cheat in a mobile wallet scenario. They argue that it would be risky for providers to do so because the mobile wallet can constantly check for cheating attempts, and the provider would suffer reputation loss if caught. Therefore, the sender believes that adding complexity to solve this issue is unnecessary.The sender clarifies a previous statement about the danger of signing "commitments" by wallet providers. They explain that it is dangerous for the provider's reputation if the service is only best-effort, as there are race conditions in the lightning protocol that may prevent the provider from having the latest state of the mobile wallet. Keeping track of the mobile wallet's state is not straightforward.The main topic discussed in the email is related to the design choice of sending data in existing messages. There is a length issue because the `commitment_signed` message may already fill up the message, leaving no room for an additional backup.To further explore the discussion, the sender provides a link [1] that contains the end of the discussion on the mentioned design choice. The earlier comments in the link provide more details on that specific design decision.Overall, the email highlights the potential risks and complexities associated with cheating attempts by wallet providers in a mobile wallet scenario. It also raises concerns about the danger to the reputation of wallet providers when signing commitments and addresses the issue of sending data in existing messages.
Updated on: 2023-08-18T01:50:20.435151+00:00